AFAIK modern browsers all use GPU accelerated rendering, so using HTML/CSS does give you a GPU-backed user interface.
Also desktop PWAs are IMO underrated and a really good way to distribute a desktop app without having to bundle a whole browser engine with your app. We do this for Construct (www.construct.net) - a complete game development IDE - and I think it's worked out great.
Saying HTML/CSS is "GPU-backed" gives the wrong impression.
What's the point of saying a UI is GPU-backed (which usually means a UI hand-crafted using mesh, texture atlas, shaders, minimal draw calls, etc.) if it's also grouped together with one of the most bloated and inefficient means to output pixels on the screen (HTML/CSS).
I love the web, not hating at all, but this is comparing apple and oranges.
The point is that GPU-backed is faster than not, which is why your browser (and your OS) is doing all those things except maybe hand-crafted meshes (and I don’t agree that hand-crafted meshes is the usual definition of a GPU-backed UI). The GPU-backed UI does benefit from simple things like faster scrolling, especially on high DPI displays, in addition to speeding up the rendering of new pixels for HTML/CSS/SVG/image/video elements. The point is the browsers are actively trying to fix the inefficiency you’re referring to, and it might now be further along than you think.
BTW, the GPU-backed browser UI and GPU-backed OS UI, these come with a bunch of things that someone’s hacked UI doesn’t, namely transparent software fallback when a GPU isn’t available, full compatibility with the UI spec, accessibility support, and tolerance for a wide range of GPUs. People making their own UIs directly almost never do these things (I’m guilty as charged), and as such their UIs are often some combination of more brittle, device dependent, and limited to a narrower audience.
Yes sir, I did in fact read the article. I used to work in game dev. After that I built a WebGL-based whiteboard a lot of people used. Now I help make GPUs. I think it’s great if you agree with the author.
> The browser is GPU-accelerated, it is not what anyone in the industry would consider a GPU-Backed UI.
Now this is a different argument than what you said above. I agree that browsers are what make it GPU-backed, not the HTML/CSS spec per se. But HTML/CSS is becoming effectively a GPU-backed UI in practice, by virtue of the fact that all the browsers use GPUs to render HTML & CSS. This is also true of the UIs provided by Windows and MacOS and Linux - the UI isn’t required to use the GPU, but the OSes will use GPUs for performance when possible. This is all anyone here actually means when they call HTML & CSS a GPU-backed UI.
Is there a meaningful difference once there doesn’t exist a modern browser that doesn’t use a GPU to significantly render web apps?
What I reject is the notion that “GPU-backed” is limited to more than what the words mean literally. If the implementation is using a GPU to render the UI elements, then it’s GPU backed. It doesn’t need to be hand-coded, or a one-off, or using shaders, or guaranteed by the UI spec.
> What I reject is the notion that “GPU-backed” is limited to more than what the words mean literally.
This is exactly what I'm arguing against. We name stuff to represent something. The article very explicitly mention "GPU-Backed UI" as one of the alternative to app that are made with web tech (HTML / CSS). Because it is talking about a very specific way to build UI. And the name they choose is "GPU-Backed UI", which is what anyone would use too.
But you are arguing that a Web Page / Browser / HTML / etc is "GPU Backed UI" and should be group together. But then we have the issue of how we name that type of UI that they are talking in the article which is very obviously something different than what a UI built using a browser would be.
Why do you say it’s a “name”; why are you assuming & asserting the words “GPU backed” are a term of art? Do you have any references to support this assertion? Why do you disagree that UI implemented with a GPU can be called “GPU backed”; aren’t overloaded meanings common enough to consider them possible and reasonable? What, exactly, is your definition of “GPU backed” then? Does it make room for the fact that OpenGL can run on a CPU? I would also argue that Scaleform on the Wii is GPU backed UI, for example.
This thread is now hung on a gate-keeping technicality, and has lost the actual point, which is that, regardless of what you want to call it, html & css rendering have been getting faster due to the increasing use of GPUs, which is narrowing the gap between bespoke UIs and interfaces made with more standard toolkits.
With that definition, could you give an example of something that isn't GPU-backed? As far as I'm aware the GPU is always there at the bottom of the stack, pushing bits to the monitor. Heck in many desktops the monitor plugs directly into the GPU!
Not saying I disagree HTML can be fast, in fact I think it's quite a bit faster than the vast majority of homecooked solutions. But tautological categorization isn't very helpful.
Now this is a distinction worth discussing, you’re right. I do assume that “GPU backed” means you’re interfacing with the hardware acceleration features of the machine, and not only using the frame buffer as pixel storage. This is what I mean when I say all the major browsers and OSes are “GPU backed”, and I’m not trying to sneak in a silly tautological straw man about the GPU being the only connection to the monitor. The browsers and OSes are making increasing use of GPU APIs for hardware acceleration like Vulkan, Metal, and DirectX, and that is what I think of when I read or
say “GPU backed”.
Makes sense. I was going to propose a line at "cpu writes to memory-mapped io pins directly controlling pixel data". The two definitions seem roughly equivalent.
In any case, HTML surely meets the criteria. A much more significant gain is to be had via performance engineering JS than translating it as-stands to rust, wasm, or any other "closer to the GPU" thing. And if comparing two post-optimizations, the HTML/JS will be much easier to debug, style, and make accessible, with practically identical performance.
In fact the flexibility of JS/TS may make the process of discovering a higher performing algorithm/data structure easier, resulting in a faster implementation than had the same amount of effort been dedicated to a worse algorithm in a "faster" language.
Important to note JS can get pretty close to the metal itself with glsl where it matters, while keeping the rest of the app traditional web tech.
> Trying to push the narrative that HTML / CSS is somehow a GPU-Backed UI is almost comical.
To me it rather seems like there are different definitions of what GPU-backed means.
>The browser is GPU-accelerated, it is not what anyone in the industry would consider a GPU-Backed UI.
In which industry?
As a former web dev I would consider any calculation GPU-backed if it is utilizing a GPU.
With that definition and considering html/css is used to build user interfaces, rendering in modern browsers could certainly be called GPU-Backed UI.
If this is a term that already has a different meaning to just the words it is composed of, that's fair to mention.
But it doesn't help a discussion to escalate using wording such as "Trying to push the narrative ... is almost comical"
It is stated right there in the article that "GPU-Backed UI" is one of the alternative to the mainstream way of building app nowadays that are basically just web page.
Now people argue that web page are "GPU-Backed UI".
I get the word might be misleading, but the article is talking about a specific way of building UI using the GPU, which does not include web page, so trying to fit the web into that category makes no sense.
In some loose sense every UI is "GPU-Backed", so how do we name that specific way of building UI that the article is mentioning? They choose "GPU-Backed UI" which if anyone would have told me those words I would immediately know what they are talking about and I would've never included HTML/CSS in that category (even if in some broad loose sense of the words it does fit).
That's a good point. So up to which abstraction level would you consider "GPU-Backed UI" to be the right term? Looks like it doesn't end with low level APIs like OpenGL as the article also mentions e.g. the rust framework https://github.com/emilk/egui
Drawing a line is always hard (when did in our evolution we become sentient?), but HTML / CSS is probably the furthest you can be from that line in modern UI tooling.
As long as the UI or it's underlying engine was built with GPU in mind and not as an after-thought to accelerate it, it can be safe to say it probably fit the "GPU-Backed UI" definition.
All I'm saying is that the article refer to "GPU-Backed UI" as a very specific way of building UI which doesn't include HTML / CSS.
Which is very different than saying that it doesn't use the GPU. Virtually every UI solution is "GPU-Backed", but when I hear the term "GPU-Backed UI", I know exactly what type of UI architecture they are talking about.
Not really it is a bit more subtle than that, unless you do some magic incantations with CSS, like z-ordering or transforms, it may bet that software rendering is used instead.
There are a couple of talks regarding CSS tricks to force GPU redrawing.
I think that was the case several years ago but I thought these days much more of the browser rendering pipeline was automatically GPU accelerated. It's hard to find up-to-date references (would appreciate any links) but for example going to chrome://gpu shows it using GPU acceleration for both compositing and rasterization (including "multiple raster threads"), as well as the usual suspects like video decoding, canvas and WebGL.
Do we know for sure if this is still true in modern browsers?
Browser makers are constantly updating their rendering engines and these pieces of wisdom do go out of date so it's important to verify them every few years.
> We do this for Construct (www.construct.net) - a complete game development IDE - and I think it's worked out great.
Mind sharing what you used for backend / frontend of your desktop PWA? I'm planning to work on a similarly complex UI and have been searching around for best-in-class (or best-trade-offs) technologies today
Any books, tips, tutorials, whatever you can share that inspired your architecture decisions would be ___immensely___ appreciated.
We have an in-house UI library, mainly because we started writing code in the mid-2010s and there was nothing good out there at the time. Maybe that's changed but while I haven't researched it thoroughly, I also haven't come across anything that looks like it does everything ours does. But our UI lib aims to be as simple and straightforward as possible, standard model-view-controller, no virtual DOM, making full use of HTML and CSS features. Personally I view a lot of modern CSS frameworks with suspicion as they all seem to massively overengineer this stuff. We have a whole desktop IDE running on basically old fashioned desktop app engineering style but on top of HTML, and it works great.
Apart from a few extra services on the side, the main app is all static resources so no real backend to speak of. Again, engineered like a traditional desktop app with everything running locally, which also means the UI always responds promptly (no waiting for network) and it all works offline.
Maybe I should write up a blog post about how it all works, but not sure how many people out there want to hear more!
If it's any indication, I posted a link on a related topic earlier today and it made the front page, so I think folks are definitely interested in the topic ;-)
Also desktop PWAs are IMO underrated and a really good way to distribute a desktop app without having to bundle a whole browser engine with your app. We do this for Construct (www.construct.net) - a complete game development IDE - and I think it's worked out great.