The article is pretty good, but maybe I’m not following the initial github thread that sparked it?
Casey Muratori (who to my knowledge is a pretty experienced/capable programmer), complains “rendering is too slow, here’s some benchmarks to prove it”,
lots of back and forth over how best to do it (I’m not going to pretend that I fully grok text rendering/gpu processing)
Person at MS says “that’s way more complicated than you think (i18n, legacy stuff, etc), this is lots of hard work”
Casey says “I don’t see why you’re making this complicated, peace”
I don’t know if Casey is right or wrong, but I missed the part at the end (that is crucial to the gist of the article), where somebody proves Casey is right with a working demo. Is it in another thread? Or did I miss his/somebody else’s benchmark example that would have satisfied the “it’s complicated” criticism?
Casey is the one who wrote the proof-of-concept terminal to support his claim. His first version was written in a weekend without an optimization work. (NB: there’s a bit of debate about this. Casey says he didn’t look at the output of a profiler, he just implemented the code with mechanical sympathy. Some would say that taking the hardware in consideration is optimization, others would say it’s reasonable use.) A couple weeks later, he demo’ed a second version of his terminal where he addressed some of the criticisms that he received.
Is that in the thread? I didn’t see that his examples address (or seem like it could reasonably attempt to ) all of their concerns. Yes his is faster (and kudos to him for proving it), but that’s not the only issue at play.
I’m extremely skeptical that they ignored his proof of concepts purely out of pride. It seems to me like they made an engineering decision (which might be right or wrong) that the proof of concept seemed to faster, but didn’t solve their other concerns/problems.
My larger point is that all of the above is a counter example to the thesis of the article. Sometimes stuff is hard and people show up and say “this is easy” when it is not.
Assuming Casey’s proof of concept is faster and addresses all of the factors then the article is well-served by the github thread. But I don’t see that.
I didn’t see that his examples address (or seem like it could reasonably attempt to ) all of their concerns.
I think Casey’s argument in the GitHub issue is that many of the “objections” raised are irrelevant to the essential question of whether the particular problem he identified is solvable with a reasonable amount of effort by someone with expertise in these areas. I don’t know enough about the problem space to personally be able to judge whether that claim is true or not, though.
I’m extremely skeptical that they ignored his proof of concepts purely out of pride.
I don’t think that’s what the author of this blog post was trying to say—my read was that they thought the Microsoft folks lacked the expertise to identify that the issue should be or is resolvable with a reasonable amount of effort, as Casey claimed.
Sometimes stuff is hard and people show up and say “this is easy” when it is not.
That’s absolutely true, and probably more often the case than not, but one must imagine that at least sometimes the opposite happens, too (someone shows up and says “this is easy”, and it actually is—or at least, it is for them).
Either way it’s a tricky situation—I felt like in general everyone in the thread was respectful to each other, but one side’s perspective on the issue was “this should be easy but no one seems to understand this and is talking circles around my efforts to solve the problem”, and the other’s was, “this person is claiming this thing is easy but they don’t seem to understand that actually it’s not”. I suppose a proof-of-concept does seem the most reasonable way to resolve a disagreement like this.
I don’t know if Casey is right or wrong, but I missed the part at the end (that is crucial to the gist of the article), where somebody proves Casey is right with a working demo.
This entire article turns on whether Casey was right, so it’s important to double-check that evidence. They did write a demonstration terminal and publish an explanatory video explaining their approach. Personally, their argument is very convincing to me, because I’m familiar with similar techniques in Xorg for accelerating text rendering (see the “Glyph Rendering” section of Xorg RENDER protocol documentation for details.)
I’m late to this story, so was unaware of any evidence outside of the thread. And it looks like the video was made after Casey closed the thread? Maybe it’s worth revisiting the github issue (either on Casy’s or MS’s part).
Thanks for sharing that! I look forward to watching it and getting a better grip on the technical issue.
The article is pretty good, but maybe I’m not following the initial github thread that sparked it?
I don’t know if Casey is right or wrong, but I missed the part at the end (that is crucial to the gist of the article), where somebody proves Casey is right with a working demo. Is it in another thread? Or did I miss his/somebody else’s benchmark example that would have satisfied the “it’s complicated” criticism?
Casey is the one who wrote the proof-of-concept terminal to support his claim. His first version was written in a weekend without an optimization work. (NB: there’s a bit of debate about this. Casey says he didn’t look at the output of a profiler, he just implemented the code with mechanical sympathy. Some would say that taking the hardware in consideration is optimization, others would say it’s reasonable use.) A couple weeks later, he demo’ed a second version of his terminal where he addressed some of the criticisms that he received.
Is that in the thread? I didn’t see that his examples address (or seem like it could reasonably attempt to ) all of their concerns. Yes his is faster (and kudos to him for proving it), but that’s not the only issue at play.
I’m extremely skeptical that they ignored his proof of concepts purely out of pride. It seems to me like they made an engineering decision (which might be right or wrong) that the proof of concept seemed to faster, but didn’t solve their other concerns/problems.
My larger point is that all of the above is a counter example to the thesis of the article. Sometimes stuff is hard and people show up and say “this is easy” when it is not.
Assuming Casey’s proof of concept is faster and addresses all of the factors then the article is well-served by the github thread. But I don’t see that.
I think Casey’s argument in the GitHub issue is that many of the “objections” raised are irrelevant to the essential question of whether the particular problem he identified is solvable with a reasonable amount of effort by someone with expertise in these areas. I don’t know enough about the problem space to personally be able to judge whether that claim is true or not, though.
I don’t think that’s what the author of this blog post was trying to say—my read was that they thought the Microsoft folks lacked the expertise to identify that the issue should be or is resolvable with a reasonable amount of effort, as Casey claimed.
That’s absolutely true, and probably more often the case than not, but one must imagine that at least sometimes the opposite happens, too (someone shows up and says “this is easy”, and it actually is—or at least, it is for them).
Either way it’s a tricky situation—I felt like in general everyone in the thread was respectful to each other, but one side’s perspective on the issue was “this should be easy but no one seems to understand this and is talking circles around my efforts to solve the problem”, and the other’s was, “this person is claiming this thing is easy but they don’t seem to understand that actually it’s not”. I suppose a proof-of-concept does seem the most reasonable way to resolve a disagreement like this.
This also confused me; but I think this is the working demo (it’s written by Casey): https://github.com/cmuratori/refterm
This entire article turns on whether Casey was right, so it’s important to double-check that evidence. They did write a demonstration terminal and publish an explanatory video explaining their approach. Personally, their argument is very convincing to me, because I’m familiar with similar techniques in Xorg for accelerating text rendering (see the “Glyph Rendering” section of Xorg RENDER protocol documentation for details.)
There’s also a followup video for Refterm v2.
I’m late to this story, so was unaware of any evidence outside of the thread. And it looks like the video was made after Casey closed the thread? Maybe it’s worth revisiting the github issue (either on Casy’s or MS’s part).
Thanks for sharing that! I look forward to watching it and getting a better grip on the technical issue.