Blur optimizations (round N+1)

Blur is still less than optimal, because it is a transformer. This means:

• If the view has a subsurface (for example, using SSD), the view's contents need to be copied to an auxiliary buffer which is then passed on to blur, which mixes it with the blurred background.
• If a view has another transformer (for example wobbly, wrot), the view is rendered to an auxiliary buffer from the other transformer and again composited by blur

We can change how blur works to make it faster:

• Introduce new signals, view-render-begin, view-render-end. It might need a bit of a reorganization in core.
• On view-render-begin, if a blurred view starts rendering, clear the alpha channel of the framebuffer and read background contents (both concern only the view bbox region). The first part is hopefully very fast, the second one is necessary anyway.
• Blur the copy (necessary anyway)
• view renders as usual (no extra copies for blur)
• on view-render-end, render the blurred background on top of the view, and use GL_EXT_shader_framebuffer_fetch to read the view's contents from the framebuffer and blend directly. (also a necessary step)

Downsides:

• This will require the GL_EXT_shader_framebuffer_fetch extension. I don't know how widely supported it is.
• This needs to be tested, it might be that we hit a slow path in some drivers and performance could be worse.

Start by tracing the existing blur transformer and core rendering lifecycle, focusing on where view rendering begins and ends. Assess the proposed view-render-begin and view-render-end signals, framebuffer-fetch requirement, auxiliary-buffer removal, and driver performance; done requires validated rendering behavior and performance testing.