Live data from Hacker News

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

idiallo.com

111–120 of 122 posts

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

#111
post #108

Earlier quoted context omitted.

> I believe there's also a setting for scrolling or how pages move back in fort I'm struggling to parse that sentence, please elaborate.

"move back and forth" I think is what they were going for, but proofreading isn't a thing anymore.

Ehh more like spellcheckers aren’t something you only get in a word processor anymore, and autocorrect doesn’t help either. I’m getting the impression that there are much more malapropisms on the Internet (and much, much fewer outright typos and spelling errors) than there used to be, say, a decade ago, and I strongly suspect spellcheckers are to blame.

(Proofreading in professional publishing is, indeed and to that industry’s great shame, much less of a thing than it used to be, but that’s a different story.)

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

#112
post #2

they already got caught artificially slowing older iphones on ios updates, remember that? this is a way to slow older models and get away with it.

It was a choice between two options in phones with bad batteries: - Slow down the phone so that it still works - Crash phone immediately Seems like the majority of people would've wanted option 2 for some strange reason? They did fix it by giving people the option, but I wonder how many still opted for "yes, I want my phone to suddenly just die instead of slowing down". And the fix for all this was a 50€ battery repl…

do you work with technology and you swallowed that crazy excuse?

"oh we're protecting you. it's not like we have a dozen voltage and temperature sensors, and not like we already throttle when those sensors detect any of the things we're claiming in the excuse" ... and everyone fall for it. geez.

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

#114
post #33

Earlier quoted context omitted.

Great. Let's not slow down CPUs coupled with aging batteries and instead have a full system crash suddenly at the most demanding moment. Sure that would be much better.

None of that was communicated previously which made many customers buy a new iPhone instead of replacing the battery. I wonder why... /s

True, but it’s no longer the case.

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

#115
post #44

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…

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.

> Beta versions are always slow and sluggish. Just install the latest beta

I never though HN will be a source for paradoxes.

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

#116

Earlier quoted context omitted.

Great. Let's not slow down CPUs coupled with aging batteries and instead have a full system crash suddenly at the most demanding moment. Sure that would be much better.

On top of that, hard crashes and partial brownouts due to undervolting can and do lead to data corruption on all sorts of storage, no matter if eMMC, straight NAND or microSD cards. Most phone PCB designs do not account properly for the scenario "battery gone bad leads to undervolting of components" at all, the best you're gonna get is the BMC cutting off everything when the voltage at the battery drops way too much…

> Most phone PCB designs do not account properly for the scenario "battery gone bad leads to undervolting of components"

We were talking about Apple here. If they don't know that a battery can get discharged, maybe they shall do something else. For a SWE might be ok. For a HWE no.

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

#117
post #115

Earlier quoted context omitted.

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.

> Beta versions are always slow and sluggish. Just install the latest beta I never though HN will be a source for paradoxes.

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

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

#118

Earlier quoted context omitted.

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

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

> I was under the impression that for GPU accelerated GUIs, all windows are rendered to a render target.

Each window renders to one or more buffers that they submit to the display server, which will then be either software or hardware composited ("software" here referring to using the GPU to render a single output buffers vs. having the GPU scanout hardware stitch the final image together from all the source buffers directly).

Note that in the iPhone cases, the glass blur is mostly an internal widget rendered by the app, what is emitted to the display server/hardware is opaque.

> It might be that windows underneath have gone to sleep and aren't updating,

The problem with blur is when content underneath does update, it requires the blur to also update, and rendering of it cannot start until the content underneath completed rendering.

> Software renderers typically do the optimisation you're suggesting to reduce on memory and CPU consumption,

I am solely speaking about GPU-accelerated rendering, where this optimization is critical for power efficiency. It's also required to propagate all the way down to the actual scanout hardware.

It also applies to CPU rendering (and gpu-accelerated rendering still CPU renders many assets), but that's not what we're talking about here.

> I think some VNC-like protocols benefit from this kind of lazy rendering, but the actual VNC protocol just diffs the entire frame.

Most modern, non-VNC remote desktop protocols use h264 video encoding. Damage is still propagated all the way through so that the client knows which areas changed.

The frames are not "diffed" except by the h264 encoder on the server side, which may or may not be using damage as input. The client has priority for optimization here.

> Their very nature makes the kinds of graphics demands of a 2D GUI very negligible.

An iPhone 16 Pro Max at 120 fps is sending 13.5 Gb/s to the display, and the internal memory requirements are much higher. This is expensive.

Not rendering a texture and being able to pass it off to scanout hardware so that the render units can stay off is the difference between a laptop giving you a ~5 hour battery life and a 15-20+ hour battery life.

The GPU could texture your socks off, but you're paying a tax every microsecond your GPU's render units are active, which matter when you're battery powered or thermally constrained. This is why display servers and GUI toolkits go through lengths to not render anything.

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

#119

Earlier quoted context omitted.

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…

Yeah, The “offscreen” terminology is Apple lingo: https://developer.apple.com/documentation/Metal/customizing-... The buffers are not that different, it really just means “extra allocation”

It's not an uncommon terminology in the WSI portion of graphics APIs, I was just pointing out that it doesn't actually mean anything to the hardware/lower stack. There are only buffers.

(There can be restrictions on which buffer formats and layouts can be used for certain things, scanout being particularly picky, but a regular window can be textured from pretty much any buffer.)

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

#120

Earlier quoted context omitted.

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

> I was under the impression that for GPU accelerated GUIs, all windows are rendered to a render target. Each window renders to one or more buffers that they submit to the display server, which will then be either software or hardware composited ("software" here referring to using the GPU to render a single output buffers vs. having the GPU scanout hardware stitch the final image together from all the source buffers…

> Note that in the iPhone cases, the glass blur is mostly an internal widget rendered by the app, what is emitted to the display server/hardware is opaque.

This sounds wild to me, so I'm just going to ask. Do you work on these kind of optimisations for a modern OS? If so, just ignore my ponderings and I'll just accept what you're saying here.

I honestly couldn't imagine this kind of compositing not happening completely on the GPU or requiring any back and forth between the CPU and GPU. That is, the windowing system creates a display list, and that display list is dispatched to the GPU along with any assets it requires (icons, font etc.). I'd also imagine this is the same as how the browser renders.

As for optimisations, if the display list is the same for a particular render target (e.g., window, widget, subsection, or entire screen), there's no reason to rerender it. There's no reason to even rebuild the display list for an application that is asleep or backgrounded. Tile-based culling and selective update of the screen buffer^ can also happen at the GPU level. Though hierarchical culling at the CPU level would be trivial and low-cost.

This is not my wheelhouse, so perhaps I'm missing something crucial here.

^ Edit: It does look like the Apple silicon GPUs do use tile-based deferred rendering.

https://developer.apple.com/documentation/metal/tailor-your-...

Post reply on HN