Unlikely. Frosted glass blur was introduced almost twelve years ago in iOS 7, and was supported all the way down to the iPhone 4. Many apps like control center have used a full screen blur without any performance issues for a long time.
Apple at the time created their own 'approximate gaussian blur' algorithm specifically to enable this, and it ran crazy fast on devices where a simple gaussian blur would barely achieve double digit FPS. Even if this 'liquid glass' effect is heavier to compute, on the hardware we have today it will be a negligible performance concern.
> Unlikely. Frosted glass blur was introduced almost twelve years ago in iOS 7, and was supported all the way down to the iPhone 4. Many apps like control center have used a full screen blur without any performance issues for a long time.
"Without any performance issues"? Entirely false - reviews at the time noted iOS 7 dramatically reduced battery life - all across the board for Apple devices, even for the then latest iPhone 5S and 5c (https://arstechnica.com/gadgets/2013/09/ios-7-thoroughly-rev...).
The abuse of transparency/translucency in the UI was the primary reason - you could go to Accessibility settings and disable animations + transparency/translucency and get notable increases in both runtime speed of the OS UI and battery life.
Indeed, I remember the switch to iOS 7, for me battery life seemed to get slightly worse but there were conflicting opinions at the time. It's fresh in my memory as it was around the same time I binged on all five seasons of Breaking Bad :)
I's also true that iOS 7 made the 4/4S seem much slower, but the frosted glass effect still ran at 60FPS - that was my point. It was really impressive at the time. Though unless you spent hours sliding the control center up and down, it's hard to blame the blur effect for the reduced battery life, as it rarely appeared inside apps. Most likely the result of increased OS bloat and proliferation of background services.
You can’t judge battery life and performance off a .0 release when the priority is on delivering features with the minimum number of showstopper bugs. At least wait until the .1.
It has been like this for every Apple release for over 20 years.
Maybe for "Apple", but there's one team that takes performance seriously. The WebKit team has a zero tolerance policy for performance regressions (https://webkit.org/performance/) dating back to the implementation of the Page Load Test in 2002 (Creative Selection, p. 93).
WebKit sounds like the kind of scrappy startup Apple might want to acquire and gain some hard-earned engineering knowledge.
If Apple has been shipping betas for 2 decades that do not meaningfully prepare the release candidate for users, something is horribly wrong. They're either not listening to the feedback they receive or they're not giving themselves enough time; both are firmly within Apple's control.
Well, firstly, this is a developer beta. So the target audience are developers that want to get a head start on getting their app(s) ready. So measuring battery performance of those dev betas is dumb.
Also, they do listen to feedback and do gather it. They won't change entire design language now tho.
The parent comment wasn't talking about the developer beta, they were talking about the .0 release. They should use the release candidates as an opportunity to dogfood new solutions instead of shipping an MVP to prod.
It’s almost certain to be a fairly cheap thing, at least for a GPU that can sling pixels at the gigabytes per second necessary to get smooth touch scrolling at these screen resolutions.
The demos only show a very limited array of shapes. Precompute the refraction, store the result in a texture, and the gist should be sample(blur(background), sample(refraction, point)). Probably a bit more complicated than this—I’m no magician of the kind that’s needed to devise cheap graphics tricks like this—but the computational effort should be in that ballpark. Compared to on-device language models and such, I wouldn’t be worried.
(Also, do I need to remind you of the absolute disdain directed by 95/98/Me/2000 users at the “toy” default theme of XP? And it was a bit silly, to be honest. It’s just that major software outfits don’t dare to be silly anymore, and that way lies blandness.)
> It’s just that major software outfits don’t dare to be silly anymore, and that way lies blandness
Great observation! We need some of that sillyness back. Everything is all serious and corporate nowadays, even 'fun' stuff like social media or games. Even movies can't be silly anymore.
Not sure about 'serious and corporate', the big corps like to appear cute, folksy etc. and recently we even saw new Google Material Design advertised as judged more "rebellious" by focus groups. Maybe bland and toothless is just a general direction of contemporary culture and style that they follow.
Myself, I can appreciate corporate stuff presenting corporate. More truthful, feels a little less manipulative.
>It’s almost certain to be a fairly cheap thing, at least for a GPU that can sling pixels at the gigabytes per second
Okay, but what about the battery connected to the GPU? The battery in my iPhone has already degraded below 80% health in the 2.7 years I've had it, so I'd rather not waste its charge on low-contrast glass effects.
> And all of this just to make the whole UI white and generic.
3:30–3:45 in the video is painful. Describing “giving you an entirely new way, to personalise your experience”, while showing… white. White white white. Oh, and light tinted backgrounds to set your white on. I hope the personalisation you wanted was white.
We used to have such customisation, then it kinda went away for a while because it was too hard and limited development, and then dark mode was hailed as a brilliant new invention.
But it is worth remembering that dark mode does actually get you some things; it’s not all bad: the restrictions do have some value.
Full customisation became paradoxically limiting: when you give too much power to the user, the app is essentially operating in a hostile environment. Of course, a lot of it was laziness on app and UI framework developers’ parts, but it really did limit innovation, too.
Dark mode gets you a pair of themes that you can switch between easily, and an expectation that there are only two themes you need to consider, with well-defined characteristics. This is a much more practical target, a vastly easier sell for app and framework developers.
The funny thing with monochrome icons is that in some ways they were actually a better fit for a full-customisation environment, where you had arbitrary background and foreground colours. Once it’s just mundane light and dark themes, you could more safely have full colour in two variants.
Certainly light mode and dark mode does not mean things need to be monochrome.
From what I've seen,the refractions happen in predictable contexts so I suspect that they'll be able to create shaders, etc that will limit the performance hit
I would imagine that for a known geometry of glass, you can do the ray tracing once, see where each photon ends up, and then bake that transformation into the UI. If you do this for each edge and curve your UI will produce, you can stitch them together piecewise to form UI elements of different shapes without computing everything again from scratch.
Early iPhone hardware was barely keeping with rendering the UI with a total ban on transparency. Even on iPhone 4 which improved the hardware a lot had the issue that it also increased amount of pixels to be pushed around.
And yes, later iOS on early hardware was huge PITA and slowdown.
I suspect that their new technique implements the existing fast gaussian blur, and since the patent is about to expire, it was a good time to spice it up.
I suspect as others have mentioned here, they use a "Liquid Glass" shader which samples the backing layer of the UI composition below the target element and applies a lens distortion based on the target element's border radius, all heavily parameterized so as to be used with the rest of the system's Liquid Glass applications like the new icon system.
Surely it's a performance nightmare because whatever is behind the frosting has to be rendered in full. Without this it can see that it's occluded and not have to render. Or does MacOS not do that?
Apple at the time created their own 'approximate gaussian blur' algorithm specifically to enable this, and it ran crazy fast on devices where a simple gaussian blur would barely achieve double digit FPS. Even if this 'liquid glass' effect is heavier to compute, on the hardware we have today it will be a negligible performance concern.