Aren't most native UI toolboxes also GPU-backed? For example Quartz on macOS is. I assume that Windows has something similar, too. Someone else mentioned GTK4 is on Linux. If you want a fast, accessible, user-friendly GPU-back UI, just use the native one.
I keep hearing that learning 2 or 3 native UI frameworks is too much work and too costly, and the answer keeps being to learn yet another new cross-platform UI framework that creates apps that are some combination of slow, lack useful features, and don't look right to the users. At this point, wouldn't it be less costly to just learn the native UI frameworks?
> At this point, wouldn't it be less costly to just learn the native UI frameworks?
People seem to be really unwilling to do this, I don't know why. Maybe it's a language issue. Mind you, the official Microsoft story for how to write a native app is .. messy. But its XAML-based renderers do use the GPU.
> People seem to be really unwilling to do this, I don't know why.
They are usually _horrible_ to write in. Win32 is an archaic mess. Linux doesn't even _have_ a native UI framework, X and the like don't handle widgets. GTK is the least unpleasant but crafting UIs with it is very tedious. KDE is C++ based and interoperates poorly with anything that's not C++. Wrappers exist but they vary in quality. The Apple equivalent is almost pleasant to work with in comparison even though it has its warts (iOS you can deal with it directly in Objective-C no problem, OSX is more idiosyncratic)
And then you have to repeat for all supported platform and rewrite everything.
You could use something like wxWidgets, but it's not pleasant to use either. Language bindings are still problematic.
No? Basically all the GUI frameworks are horrible to write in, and if you haven't reached a point where you're pulling your hair out then your application just isn't complex enough. There is an unavoidable amount of complexity in writing GUIs and using a cross-platform framework means you get to wade through that unavoidable complexity N+1 times: once for each platform and then once for your framework!
Microsoft sticking to XAML is one of their biggest mistake ever WRT native UIs, no wonder it's a dreaded target
Then you have both Google and Apple who invested massively into new languages and framework to facilitate the developments of apps and therefore native UIs
- Compose for Google in partnership with Jetbrains for Kotlin
- SwiftUI with Swift for Apple
Flutter in the way to make things cross-platform, all of them declarative, all of them native, all of them doesn't require learning a dedicated markup language
The problem are the politics between DevDiv (owns VS and .NET) with WinDev (owns COM, WinRT, C++).
WinRT came to be, as WinDev kept redoing Longhorn ideas in COM since Vista reboot, having .NET and C++ as the re-invention of .NET had it been fully based on COM instead of CLR (Ext-VOS original idea).
The new Windows 11 widgets started out as COM and C++/WinRT (which uses a primitive ATL like tooling), because only WinDev could come up with the idea of using COM, C++ and XML inline strings, for what Apple and Goole use nice Swift/Kotlin/Java APIs. Only after some backslash did they come up with the C# version of the API.
So we have WinDev doing WinUI 3.0/WinAppSDK, porting UWP out of the sanbox into regular Win32 stack, with lesser tooling (.NET Native, C++/CX deprecated, no designer), while DevDiv is focused on MAUI and Blazor (apparently putting into Web widgets is also a good idea).
First Microsoft needs to get rid of their internal GUI civil war.
I don’t think they are GPU backed. Fonts are rendered with CPU and draw really slow. The same with graphics primitives like lines, ellipses. A QML scene graph supports only text, images, and rectangles and the text is CPU rendered. Windows still mainly uses CPU for graphics. Video with changing text overlays is a difficult problem to do efficiently.
Does Cocoa draw controls like checkboxes and what not with the GPU?
In GTK 4's case, drawing the widgets, CSS transitions, shadows, etc is all on the GPU. Video from GStreamer arrives as GL textures, same for WebKit integration and therefore can be used with all of the other high-level render-tree snapshotting features.
I’m way out if my depth here, but isn’t certain things faster to render on the CPU still? I believe it is mostly vector graphics - I have seen a few papers showing that it can be done fast(er?) on the GPU but that may not be that widespread yet.
> but isn’t certain things faster to render on the CPU still?
It really depends on the context.
If you look at it in a certain light, fonts are just "vector graphics" and there are ways to do that without using SDF (signed distance fields) and get really high quality precisely positioned fonts fully rendered on the GPU.
An example of that is the GLyphy project and we have a branch which can render fonts using that with GTK 4. It's a bit slower, but better quality and still easily able to handle 144hz full screen text scrolling. It requires some preprocessing before uploading glyph curves to a data atlas on the GPU.
For other shapes, there are options, but given GTK has so few upstream developers, they aren't quite ready for prime-time so they'll likely be part of GTK 5 in the form of "GskPath" if you feel like browsing the branches with that.
Windows 95 rendered its UI on CPU and it was fast. You need GPU for big bitmaps and useless effects. For square with border and text CPU is more than enough. Then you send this small square bitmap to GPU to add shadows and whatnot to it.
Windows 95 doesn't even support Unicode. The level of UI you can draw there is a very small subset of what you can do in say Chrome.
Indeed correct unicode text rendering is one of the difficult problems. It's the same thing that is missing from basically all games. So when people say stuff like games can run at 120fps, how hard can UI be? it's basically the same Windows 95 argument. The UI work being done is a small subset.
I keep hearing that learning 2 or 3 native UI frameworks is too much work and too costly, and the answer keeps being to learn yet another new cross-platform UI framework that creates apps that are some combination of slow, lack useful features, and don't look right to the users. At this point, wouldn't it be less costly to just learn the native UI frameworks?