You can try rendering a 2D rectangle as 2 quads in whatever GPU API you like the most, then try pushing the same amount of pixels to a CPU buffer via the widest CPU memory write instructions you can have (and then wait the GPU-accelerated compositor upload them to the GPU anyways to present them...).
I can tell you for a fact one will be 2 orders of magnitude faster, want to make bet which one?
Using a GPU api does not imply you have to render at the screen's refresh rate, or even that you have to update the entire window.
There's a reason why browsers are so complicated and equally non performant. 2D rendering, even GPU accelerated, with the constraints we have right now (or rather, the lack of constraints, because 3D rendering is basically tradeoffs all the time), is not going to be more performant.
Text glyphs/UI images are all in 1 atlas, you can render the entire UI as 1 draw call and only re-render when something changes. I haven't checked if Claude chose to re-render the whole screen or just part of it, you can design it either way.
Layout can be as simple or as complex as you want it to be - this example does both flex and grid-style layuts, flex supports start/end/center/stretch on both main/cross axes, as well as a flex prop.
For the API you can either go immediate mode or retained - this one is retained since explaining to Claude how to do the IM version properly would take longer than doing it myself, but the layout algorithm can be the same regardless of which route you go for the user-level API.
You only need scrolling/overflow on top of that and this is enough for the majority of widgets you may need.
My point is none of this stuff is hard. This is 700 lines of Claude code, if you write it yourself it would be 400, and will have better performance characteristics than most UI libraries out there.
Edit: Added scrolling too, there's a 100K scrollable virtual list in the demo. Again - this stuff is not hard.
They are. They're not particularly more performant that what we do today. It all involves tesselation on the CPU, or dropping entire feature sets.
>But in general handling vector graphics is simply overkill.
You don't get to decide that.
>Rounded corners? We don't those! Let's use a paradigm that's more GPU friendly.
That ship has sailed. The text input I'm typing this comment in has slightly rounded corners. The text it's containing is vector graphics with rounded corners everywhere, where the best renderer solution at the moment is Slug, with SDFs being a distant second.
>Text can all be cached.
sure, if you drop ligatures, only care about latin alphabet languages, accept having to rerender everything the moment I zoom the page to 110% or 125%