Has anybody tested it yet? It is computed as GPU shader. I wonder if it is that less efficient compared to frosted glass blur effect that was there for at least a decade.
Blur is expensive because it propagates damage and has to wait for all previous rendering to be complete.
When one pixel changes underneath a blur the entire blurred area needs to be redrawn, meaning that all elements on top needs to be redrawn. As the blur cannot render before the underlay is finished, the graphics pipeline is stalled. Fancy blur look past the area immediately underneath to more accurately lens effects, meaning each output pixel reads a lot of input pixels.
When it comes to power and heat management, the goal is to be able to power the GPU down again as fast as possible, and this kind fo thing prolongs it quite a bit. There may be a point where efficiency makes the result acceptable, but it's always going to be much worse than not doing that.
No, you never compute individual pixels because you never need to, and it's always faster to it in bulk (vectorization, memory access...) and so over an area you take the same number of pixels as input (or a little bit more with padding) and the blur will only increase significantly the compute.
You misunderstood, this is not about computing individual pixels but only selective rerendering graphical elements which have been changed, and in turn figuring out the total area of change. This propagates through the entire stack to let the GPU scanout hardware know which tiles have changed, and allow partial panel self refresh updates (depending on hardware).
Rendering is still done in bulk for the changed areas, avoiding rendering expensive elements (e.g., transformed video buffers, deeply layered effects, expensive shaders). It's a fundamental part of most UI frameworks.
Are windowed GUIs still doing diffed screen updates? I would have assumed that GPUs make this kind of thing very unrewarding to implement as an optimisation. I'd imagine every window is being redrawn every frame as a 2D billboard with textures and shaders.
The Guassian blur and lensing effects would still slow things down by needing to fetch pixels from the render target to compute the fragment, vs painting opaque pixels.
The usual mechanism is to mark widgets that changed dirty, accumulate the bounding boxes of such dirty areas, take the next swapchain buffer and get its invalid regions, iterate through the widget tree and render anything that intersects with the bounding box or invalid regions, and submit the buffer + the dirty areas to the display server/driver.
And yeah, having a render step depend on the output of a previous non-trivial render step is Bad™.
I was under the impression that for GPU accelerated GUIs, all windows are rendered to a render target. It might be that windows underneath have gone to sleep and aren't updating, but they would have their last state rendered to a texture. This permits things like roll-over previews and layered effects to have a more trivial overhead.
Software renderers typically do the optimisation you're suggesting to reduce on memory and CPU consumption, and this was a bigger deal back in the day when they were the only option. I think some VNC-like protocols benefit from this kind of lazy rendering, but the actual VNC protocol just diffs the entire frame.
On the GPU, the penalty for uploading textures via the bus negate the benefit, and the memory and processing burden is minimal relative to AAA games which are pushing trillions of pixel computations, and using GBs of compressed textures. GPUs are built more like signal processors and have quite large bus sizes, with memory arranged to make adjacent pixels more local to each other. Their very nature makes the kinds of graphics demands of a 2D GUI very negligible.
>you never compute individual pixels because you never need to
Pixel shaders are looking at this laughing at you. PS_OUTPUT is a single pixel whether you want it or not. PS wavefronts are usually very small, so you're still going to be doing a lot of sampling.
I suppose we have to wait for official release. Beta builds have some debug stuff which makes OS slower. This has always been the case with all previous macOS beta versions that felt slower.
When one pixel changes underneath a blur the entire blurred area needs to be redrawn, meaning that all elements on top needs to be redrawn. As the blur cannot render before the underlay is finished, the graphics pipeline is stalled. Fancy blur look past the area immediately underneath to more accurately lens effects, meaning each output pixel reads a lot of input pixels.
When it comes to power and heat management, the goal is to be able to power the GPU down again as fast as possible, and this kind fo thing prolongs it quite a bit. There may be a point where efficiency makes the result acceptable, but it's always going to be much worse than not doing that.