The article is quite nice. However, it glosses over the primary problem with shaders.
A shader is a pain in the ass that most programs and applications don't want.
3D stuff likes triangles and the GPUs are happy to slot into that abstraction. Shaders are useful to interpolate over those triangles.
Triangles are mostly garbage for everybody else. 2D rendering wants paths. Font rendering wants paths or pixmaps. GUI's would work much better with paths and pixmaps. Compositors really want pixmaps. Video decoders really want pixmaps and parallel rendering.
What everybody non-3D wants is rectangular pixmaps and access to computation directly to those pixmaps. And GPUs don't like this very much, and shaders don't map very well to this.
Having written a 2-d curve renderer, what I want is parallel compute and high bandwidth; gpus deliver. (Especially with newer interfaces that support scatter-write; not sure how much penetration these have in the browser yet.) It's true this is not what you want at a higher level, but it serves as a fine base to implement higher-level abstractions. You could support them in hardware, but it's not at all obvious what the advantages would be; no one complains that cpus don't have architectural support for for-loops.
Edit: upon a reread, I don't really understand what your problem is with gpus. You can ignore the vertex processing pipeline entirely, drawing just a single fullscreen quad (or use a compute shader); the gpu will handle this with aplomb, and this is the sort of thing the linked article is talking about too.
>A shader is a pain in the ass that most programs and applications don't want.
As a devil's advocate: most programs don't necessarily require the GPU to achieve what they want. 3d stuff nigh requires such parallelism once you go past a very small scale.
That was the mindset in the 00's at least. Software has gotten more complex to the point where the GPU may be a desired optimization to make, but the GPU pipeline has always been strict and closed down, and the paradigms from single to multi-core programming often require different algorithms. GPGPU programming can liberate you from the need to work in triangles, but you still need to take a completely different approach if you want to enjoy that parallelism.
Only interpolating based on the edge? Needing to carefully map float coordinates so you don't wind up with fractional pixels mapping incorrectly? Inability to look at pixels to each side to compute something?
You can work around the limitations in vertex or fragment shaders, but, in many cases, you're having to unwind a lot of what the vertex and fragment processing does.
On of my favorite examples is drawing a screen/pixel-space rectangle and then drawing a border of the rectangle in a different color and specifying the number of pixels that border should be wide. Oof. You have to specify 4 triangles, make sure they don't overlap, specify them in a particular vertex order or annotate them with extra data so you only draw one of the three edges, make sure that you only draw each pixel just once or your blending goes all to crap, etc. Whereas, you can divide the rectangle into chunks, send each chunk through the compute pipeline, and it's stupidly straightforward.
Or, if you want simpler, just draw a line n pixels wide. If you don't have an explicit extension to do this, it's really a pain.
2D graphics simply wants very different graphic and computational primitives compared to 3D.
Interpolation works on neighboring pixels though? Not sure what you mean there. Looking at neighboring pixels of the input pixmap is trivial as well.
The fractional pixel mappings do get you - but I think I recall an integer mode somewhere in GLSL 3.2.
Your example steps outside the shader boundary, though. If you try to use triangles to draw pixmap, of course you'll have trouble. That's why pixel shaders are the right tool for the job.
The only disadvantage they have is that the pixmaps are immutable within a single pass, so you can't (easily) draw the border together with the inner rectangle in one pass. But if you're used to functional programming, you won't even notice this.
I agree that shaders are not the right thing when you need mutability, as you seem to, but working with 2D graphics doesn't necessarily require mutability.
A shader is a pain in the ass that most programs and applications don't want.
3D stuff likes triangles and the GPUs are happy to slot into that abstraction. Shaders are useful to interpolate over those triangles.
Triangles are mostly garbage for everybody else. 2D rendering wants paths. Font rendering wants paths or pixmaps. GUI's would work much better with paths and pixmaps. Compositors really want pixmaps. Video decoders really want pixmaps and parallel rendering.
What everybody non-3D wants is rectangular pixmaps and access to computation directly to those pixmaps. And GPUs don't like this very much, and shaders don't map very well to this.