Live data from Hacker News

Liquid Glass? That's what your M4 CPU is for

idiallo.com

81–90 of 122 posts

Re: Liquid Glass? That's what your M4 CPU is for

#81
post #11

I'm inclined to believe what 'mitchellh wrote: "The Liquid Glass effects are not expensive and anyone claiming they are has no idea how modern GPUs and animation work. Anyone saying it is is either just parroting or is an idiot." https://x.com/mitchellh/status/1933314816472723728

I agree with Mitchell. Gaussian blurs are some of the most expensive operations you can run, and Apple has been using them for a long time. They’re almost always downscaled because of this. The first retina iPad (the iPad 3 if I recall) had an awfully underpowered GPU relative to the number of pixels it had to push. Since then, the processors have consistently outpaced pixels. Your device is easily wasting more time…

A Gaussian blur is separable, making it far more efficient than many other convolutional filters, and convolutions are hardly the most expensive sorts of operations you could run.

Re: Liquid Glass? That's what your M4 CPU is for

#82

Earlier quoted context omitted.

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 effe…

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 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.

Re: Liquid Glass? That's what your M4 CPU is for

#83
post #11

I'm inclined to believe what 'mitchellh wrote: "The Liquid Glass effects are not expensive and anyone claiming they are has no idea how modern GPUs and animation work. Anyone saying it is is either just parroting or is an idiot." https://x.com/mitchellh/status/1933314816472723728

Yes let’s go further https://youtu.be/3XvzlHuqlXY?si=3l52BmWcjELs-Mt8

Re: Liquid Glass? That's what your M4 CPU is for

#85

Earlier quoted context omitted.

I agree with Mitchell. Gaussian blurs are some of the most expensive operations you can run, and Apple has been using them for a long time. They’re almost always downscaled because of this. The first retina iPad (the iPad 3 if I recall) had an awfully underpowered GPU relative to the number of pixels it had to push. Since then, the processors have consistently outpaced pixels. Your device is easily wasting more time…

The problem with these kinds of blur effects is not the cost of a gaussian blur (this isn't gaussian blur anyway as it has a lens effect near the edges). It's damage propagation and pipeline stalls. When you have a frosted glass overlay, any pixel change anywhere near the overlay (not just directly underneath) requires the whole overlay to be redrawn, and this is stalled waiting for the entire previous render pass to…

Yes, that all makes sense! My understanding is that the damage propagation gets worse with depth (no limit) in addition to breadth (screen size). If the compositor has N layers, a blur layer, N more layers, another blur layer, etc. then there are a lot of "offscreen render passes" where you have to composite arbitrary sets of layers exclusively for the purpose of blurring them.

It's true that GPU is itself not busy during a lot of this because it's waiting on pixels, but whatever is preparing the pixels (copying memory) is super busy.

Downscaling is a win not just for the blurring, but primarily the compositing. KDE describes the primary constraint as the number of windows and how many of them need to be blended:

  The performance impact of the blur effect depends on the number of open and translucent windows
https://userbase.kde.org/Desktop_Effects_Performance#Blur_Ef...

Re: Liquid Glass? That's what your M4 CPU is for

#86

Earlier quoted context omitted.

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,…

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.

Re: Liquid Glass? That's what your M4 CPU is for

#88
post #44
post #11

I'm inclined to believe what 'mitchellh wrote: "The Liquid Glass effects are not expensive and anyone claiming they are has no idea how modern GPUs and animation work. Anyone saying it is is either just parroting or is an idiot." https://x.com/mitchellh/status/1933314816472723728

I'm inclined to believe what I have experienced. I have never before experienced my 2020 iPad Pro to be remotely slow. I use it for some web browsing and YouTube viewing, so I really don't need a lot of computing power. Now that I'm running the iOS 26 beta, I frequently feel animations going slowly or hitching. It's not terrible, but for the first time, I have the feeling that my experience using my iPad would be not…

Yes. The beta is discussed in the replies.

Re: Liquid Glass? That's what your M4 CPU is for

#89
post #58
post #29

Earlier quoted context omitted.

If that's so, can't he explain it ELI5 style instead of calling people idiots? I have a hard time believing that the GPU is somehow magically energy efficient, so that computing this glass stuff uses barely any energy (talking about battery drain here, not "unused cycles").

Here's an attempt at that: The GPU is responsible for blending layers of the interface together. Liquid glass adds a distortion effect on top of the effects currently used, so that when the GPU combines layers, it takes values from (x + n, y + m) rather than just (x, y). Energy efficiency depends on how much data is read and written, but a distortion only changes _which_ values are read, not how many.

It needs to read more than one value. Otherwise blurring cannot happen. That's automatically more work. And also, considering the effect being physics based, even in your example, were it correct, calculating what n and m are is not trivial.

Re: Liquid Glass? That's what your M4 CPU is for

#90

Earlier quoted context omitted.

I agree with Mitchell. Gaussian blurs are some of the most expensive operations you can run, and Apple has been using them for a long time. They’re almost always downscaled because of this. The first retina iPad (the iPad 3 if I recall) had an awfully underpowered GPU relative to the number of pixels it had to push. Since then, the processors have consistently outpaced pixels. Your device is easily wasting more time…

The problem with these kinds of blur effects is not the cost of a gaussian blur (this isn't gaussian blur anyway as it has a lens effect near the edges). It's damage propagation and pipeline stalls. When you have a frosted glass overlay, any pixel change anywhere near the overlay (not just directly underneath) requires the whole overlay to be redrawn, and this is stalled waiting for the entire previous render pass to…

[deleted]
Post reply on HN