5 ms·

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 animati

• conradev 1y ago
  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 on redundant layout or some other inefficiency rather than Liquid Glass. Software does get slower and more bloated over time, often faster than the hardware itself, not in the ways you might expect. The GPU has so much headroom that they fit language models in there!
  • ccapitalK 1y ago
    Gaussian Blur isn't the most efficient way of doing a frosted glass blur effect though. IIRC the current state of the art is the Dual Kawase blur, which is what KDE uses for its blurred transparency effect, I've never observed performance issues having it running on my machine.
  • arghwhat 1y ago
    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 complete first for the pixels to be valid to read. The GPU isn't busy in any of this. But it has to stay awake notably longer, which is the worst possible sin when it comes to power efficiency and heat management.
    • Melatonic 1y ago
      Thankfully you can probably turn it off as usual
    • conradev 1y ago
      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_Effect https://userbase.kde.org/Desktop_Effects_Performance#Blur_Ef...
      • arghwhat 1y ago
        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, 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.)
        • conradev 1y ago
  • thfuran 1y ago
    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.
• deleted 1y ago
  [deleted]
• fainpul 1y ago
  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").
  • JKCalhoun 1y ago
    My generous interpretation is that he means the GPU is magically energy efficient compared to the CPU. I wouldn't dispute that. But Apple went down that xPU-taxing path a long time ago when they added the blur to views beneath other views (I don't remember what that was called).
    • GCUMstlyHarmls 1y ago
      Translucency.
    • sillywalk 1y ago
      The translucency goes all the way back to the original Aqua interface in Mac OS X. I believe the compositing started getting some GPU acceleration (Quartz Extreme) in Mac OS X 10.2 Jaguar all the way back in 2002.
  • deleted 1y ago
    [deleted]
  • DougBTX 1y ago
    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.
    • vrighter 1y ago
      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.
• mort96 1y ago
  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 noticeably improved if I bought a new and more powerful one. But I guess this makes me an idiot according to Mitchell?
  • alluro2 1y ago
    Sounds like it's working exactly as intended.
  • andai 1y ago
    I experience this basically any time I upgrade my phone OS. There's never anything new that makes me happy, it's always either they removed something I used, made something uglier, and always it's 2-3x slower than it used to be. Same thing with Windows. If they just stopped touching it 20 years ago, it would be 50x more responsive now.
  • zuhsetaqi 1y ago
    Beta versions are always slow and sluggish. Just install the latest beta of iPadOS 18. It will be sluggish. The reason is that in beta versions there is a lot of logging and reporting running in the background which can not be disabled.
    • hulitu 1y ago
      > Beta versions are always slow and sluggish. Just install the latest beta I never though HN will be a source for paradoxes.
      • viherjuuri 1y ago
        1) that is not a paradox 2) the ending of the sentence (which you left out) gives context: iOS 18 beta is sluggish as well, so ‘being sluggish’ is not a liquid glass exclusive
• rickdeckard 1y ago
  Depends on whether "expensive" refers to a.) Compute-cycles: Some added passes to apply additional shading on top of the completed render, or b.) Power-consumption: Some added delay in putting components to sleep (reducing CPU/GPU-clock) on every screen update. Deferred sleep for a portable, battery-powered device because of a longer UI-rendering pipeline can easily add up over time. -- I'd be quite interested to see some technical analysis on this (although more out of technical curiosity than the assumption that there is something huge to be uncovered here...). There's also the aspect of iOS prioritizing GUI-rendering over other processing to maintain touch-responsiveness, fluidity, etc. Spending more xPU-time on the GUI potentially means less/later availability for other processes. For sure non-native apps trying to emulate this look (i.e. Flutter) will create a significantly higher impact on the power-profile of a device than a native app.
• ohdeargodno 1y ago
  [flagged]
• latexr 1y ago
  Alan Dye introduced the design by stating: > Now, with the powerful advances in our hardware, silicon, and graphics technologies, we have the opportunity (…) https://www.youtube.com/watch?v=jGztGfRujSE&t=42s https://www.youtube.com/watch?v=jGztGfRujSE&t=42s Coupled with the reports of sluggish performance from the early betas, it’s understandable people would reach the conclusion that the new design pushes the hardware significantly more than before.
• savolai 1y ago
  Yes let’s go further https://youtu.be/3XvzlHuqlXY?si=3l52BmWcjELs-Mt8 https://youtu.be/3XvzlHuqlXY?si=3l52BmWcjELs-Mt8
• dvfjsdhgfv 1y ago
  It would be hard to find a more "ad hominem and not ad rem" quote.