It's essentially pointing out the biggest issue with the article and then shrugging it off, while obviously putting a lot of effort into the writing.
Or you could post GIFs yourself. Maybe that seems like too much work?
Asking whether I'm willing to provide my own gif isn't quite a fair measure. The author has the code running and he himself commented on the need for moving pictures. I have partial code and no personal investment in this.
I have however written a few articles about stuff I've done for my own work and wherever it seemed relevant I've taken the time to produce and include video. That's been a lot less effort than writing the text, even when it's required a number of changes in the scenes and code.
(By sub-pixel they mean more finely determining the endpoints of the lines on an arbitrary grid finer than the output pixels — NOT physical display sub-pixels.)
> The other thing I need to do is subpixel-correct lines, because they're so much more nicer in motion than non-subpixel-correct lines. Don't confuse this with AA lines - you can have chunky non-AA single-colour pixel lines that are ALSO subpixel-correct.
> Why this is important is hard to convey in a static picture, but in motion the quality difference is very obvious. And it turns out the speed difference is not actually significant, so why not go for the extra quality?
This claim is made almost immediately in the article, but then provides no poof in picture OR video!
The breakdown of the algorithm and general writing is great though.