91–100 of 122 posts
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
More importantly, why did the version jump from 15 to 26?
Earlier quoted context omitted.
The issue was always that of communication and trust. Communication: at no point has Apple tried to communicate "your phone's battery has gone bad, the device now suffers for it" to the user. Even though they obviously knew that this was what was happening. Trust: with how openly anti-repair Apple was at the time, how can you trust that this was a honest oversight, and not another malicious action designed to prevent…
The issue has always been that people who don’t trust Apple interpret everything that Apple does in the worst possible light. I make no comment here on whether such suspicion is justified. But let’s imagine that the current behavior (showing the battery warning) had been the original behavior. Then people would no doubt have complained that Apple was trying to pressure people into unnecessary battery replacements.
IMO the actual reason for Liquid Glass is that they can do it natively. 3rd party UI frameworks can't copy it without a massive performance hit. This brings a more clear divide between fully native iOS applications and React Native -style "build once and cross-compile" -platforms.
>3rd party UI frameworks can't copy it without a massive performance hit. Do you believe pixel shaders are some unique magic that only Apple has the secret sauce to and noone else can use? There were some efficient implementations of liquid glass for flutter before the iOS beta was even released. Glass effects are dime a dozen on shadertoy, they're one of the most basic effects you could learn to do when learning abo…
(Actually, someone probably will. People are weird that way.)
I'm pretty sure any recreation will still be just that little bit off compared to the native one, which is their intention IMO.
Earlier quoted context omitted.
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 pi…
And yeah, having a render step depend on the output of a previous non-trivial render step is Bad™.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 d…
Note that there are some differences when it's the display server that has to blur general output content on behalf of an app not allowed to see the result, vs. an app that is just blurring its own otherwise opaque content, but it's costly regardless.
(There isn't really anything like on-screen vs. off-screen, just buffers you render to and consume. Updating window content is a matter of submitting a new buffer to show, updating screen content is a matter of giving the display device a new buffer to show. For mostly hysterical raisins, these APIs tend to still have platform abstractions for window/surface management, but underneath these are just mini-toolkits that manage the buffers and hand them off for you.)
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 d…
As long as the lower blur layers are not fully occluded by opaque content, then yes - they all need to be evaluated, and sequentially due to their dependency. This is also true if there is transparency without blur for that matter, but then you're "just" blending. Note that there are some differences when it's the display server that has to blur general output content on behalf of an app not allowed to see the result…
https://developer.apple.com/documentation/Metal/customizing-...
The buffers are not that different, it really just means “extra allocation”