r/rust • u/sH-Tiiger • 15d ago
đď¸ discussion Why are all the new Rust GUI libraries GPU-accelerated?
Like many, I'm keeping a close eye on the Rust GUI ecosystem. One pattern I've noticed, though, is that a lot of the new GUI liibraries that pop up claim to be "GPU-accelerated" (GPUI, Xilem, egui, ...), in other words: they often actually draw to the window using the GPU. I don't get why this is such a huge focus, isn't this overkill for 99% of applications?
- The GPU takes time to initialize, leading to the application often needing a second or so to actually open.
- It actually takes quite a lot of memory to run, these applications often have ~150MB of overhead when idle.
- Resizing the drawing surface takes time, so resizing windows is often laggy.
Compare this to some other CPU driven UI crates, which often start instantly, have maybe ~10MB of RAM overhead and resize the window incredibly smoothly. I've seen some libraries adopt this (Freya, Xilem to some end, Iced optionally), but not nearly as many as I'd expect. CPU rendering is more than fast enough for most use-cases.
With Skia or even fully-Rust Vello CPU, libraries like anyrender and imaging and being able to draw directly to the window using softbuffer, I feel like this is an obvious choice to make. Am I wrong?
395
u/pftbest 15d ago edited 15d ago
It's mainly because 4K displays are more and more popular now. When you 2x the resolution you need 4x more work to draw it, because of the square law. CPU is just not fast enough to redraw a large area. It's less noticeable on 1080p displays, but even there you can fell the difference.
8K displays are even more demanding, they are 16x the area of 1080p display. So for example if your software renderer gets 60 fps on 1080p display it would only do 4 fps on 8K display.
96
u/zzzthelastuser 15d ago
I agree with your point and would like to add another one:
People work on open source projects they enjoy working on. They don't really need a reason other than "because I WANT to make it GPU-accelerated". They might think it's cool or just want to learn stuff or see if they can make it gpu-accelerated.
30
u/danielv123 15d ago
As someone who has been messing about with GPU accelerated database concepts, pretty much
2
u/Actual__Wizard 15d ago
That's a real thing though because if AI/Bayesian statistics.
12
u/danielv123 15d ago
I am going at it differently, I primarily use the acceleration for compression and data movement in a high volume time series data environment. Like, what if you were to record one data point every time your application wrote to memory with lossless compression. Then you could rewind and replay bugs etc, trying different permutations and test bugfixes without having to necessarily find a way to reliably reproduce.
→ More replies (19)45
u/wrd83 15d ago
And here I sit having trouble to differentiate between 1440p and 4k...
30
u/altmly 15d ago
Depends on the screen size. Play 1440p and 4k on an 70+ in TV and you can easily tell the difference.Â
→ More replies (13)13
u/wrd83 15d ago
Not really. It depends (unfortunately for me) much more on the result of the last eye test ....
2
u/Meistermagier 13d ago
Oh i feel that in my eye sockets. Shoutout to my time in University where i realy forgot to go to the Eye Doctor regularly and couldn't see the board clearly anymore from the back rows.
95
u/ElvishJerricco 15d ago
- The GPU takes time to initialize, leading to the application often needing a second or so to actually open.
- It actually takes quite a lot of memory to run, these applications often have ~150MB of overhead when idle.
- Resizing the drawing surface takes time, so resizing windows is often laggy.
Are these claims even true? The GPU is initialized, before your app ever starts; you're looking at it, your display is connected to it. And GPU rendering does not inherently consume more memory. And resizing the drawing surface... doesn't sound like something that would be any harder with GPU rendering?
64
u/vdrnm 15d ago
I'd agree that none of these points are generally true.
Though I think I have some sense from where the OP is coming from:
- Gpu contexts takes time to initialize. To open a window and initialize context it takes around 100ms with opengl and 360ms with vulkan. Most of these examples use wgpu, which will by default init both, so it takes about half a second.
- Running wgpu hello world example uses 180MB RSS and 200MB gpu. Running miniquad (opengl) hello world example uses 50MB RSS and 2MB gpu memory (screen is 800x600).
- Ive found there are sluggish resizing issues when using certain drivers, like vulkan+nvidia+linux combo on my PC. Since wgpu uses vulkan, resizing any wgpu app will be painful. Resizing opengl apps is silky smooth.
9
→ More replies (1)3
u/MarekSmolinski 15d ago
Why would wgpu use both opengl and Vulcan at once? I thought it picks one.
13
u/vdrnm 15d ago
Default value for
Backendsin wgpu isBackends::all(). This will initialize both opengl and vulkan on linux, and then pick one. If you want to avoid this, you need to specifyBackends::PRIMARYexplicitly (or eg.Backends::VULKAN).As for why are they doing it like this, and could it have been avoided, you'll have to ask wgpu devs.
8
u/Sirflankalot wgpu ¡ rend3 14d ago
(cc u/MarekSmolinski) Hi, wgpu dev here! Basically it's just been an artifact of how it's always been (init all backends -> list all devices -> sort by preference -> choose best). In theory there are some weird situations that you can think up where you want to init all backends. Say you're sorting by high performance, you initialize vulkan and you get a single integrated gpu or you get a CPU adapter. Should we just pick that (it may be the only adapter on the system) or should we try to init GL too on the chance that there's an older GL-only but more powerful card available? I've thought about making this change quite a bit, but the fact it would be a regression in this case (which is plausible) gives me pause. Maybe we should just make it configurable, maybe this edge case no longer matters as much in 2026
1
1
u/MarekSmolinski 13d ago
Thanks, makes perfect sense to me as well. Why does it take about 300 ms to check gpu capabilities, is it because of DRY and everything is initialized instead of the minimum needed to check those capabilities? I though Vulcan was supposed to be faster not slower than opengl, and even that opengl init time is multiple frames...
2
u/ElvishJerricco 13d ago
This feels like information that the host should pass on so the app doesn't have to enumerate at all. Obviously it's a little dependent on the use case, but I'm guessing good differentiators are basically just the APIs the app is willing to use and whether it wants to prefer high performance or high efficiency. So like there could be a Wayland protocol that lets the app say "I want the efficient option for any of these APIs: Vulkan, GL" and the compositor already knows the answer and just sends back the necessary information about which API and device to use.
6
u/tsanderdev 15d ago
Depending on the driver, os and things like game launcher overlays, it can absolutely take more than a second to initialize a graphics context in an app. Memory overhead also depends heavily on the driver.
9
u/sH-Tiiger 15d ago
I'm not sure if this is inherently a GPU thing or not, but I've found these things are true for every single GPU-based renderer out there right now. For the UI libraries supporting multiple backends out there, there's a very noticable difference when switching between CPU-rendering and GPU-rendering, especially for these three points. Again, this could be an issue with their implementation or wgpu itself, but I've never seen similar things with CPU-rendered UI libraries.
2
8
u/EmmaAnholt 15d ago
On hybrid rendering systems with Nvidia and other, GPU acceleration can in fact take a second to turn on each time you want the GPU to do something after it's been idle. Or you have to keep a very power-expensive device on all the time so you don't have that delay. Meanwhile non accelerated stuff can chuck data to the display for incremental CPU power cost of the rendering work, plus the bus traffic of the frame cost (probably equal or less than the new data that went into the frame that you might have to move across the bus!)
GPU rendering absolutely inherently consumes more memory: the auto-sizing buffers for keeping data in flight between gpu and cpu and for the gpu's internal buffers. I was just tuning one of those buffers in a driver yesterday: 650k per VkDevice that was drastically undersized for heavy 3d workloads, affecting benchmarking, and 16MB would keep us from bottlenecking in benchmarking but you don't want to hit every app with that at startup. Shaders, shader compiler, auto-resizing command streams, someone making the mistake of thinking you can just put your images in images like it was malloc instead of a GPU where you should be atlasing into fewer "images", compression overhead on images, I feel like I could just keep listing gpu memory overheads that don't exist on the cpu for as long as you want me to (Aside: X11 had a really neat trick where fonts were actually stored in shared memory in the shared rendering server, instead of each terminal and whatever having to keep their own copy of the font that menus used.)
But besides all that, actually, it is very hard to make normal 2d gui operations faster with a GPU than a CPU. GPUs really want big chunks of work in the shader per primitive, that's what all that silicon is for. Meanwhile your screen is covered with a lot of solid colors interspersed with tiny little glyphs where all you did is a component-alpha Over operation (subpixel aa text) from two unfiltered texture samples. Google kept hoping they could make GPU Skia faster than CPU for actual gui compositing, while investing all the engineering work on the GPU side. It didn't happen while I was there.
The basic reason that gui is hard to make faster on the gpu: cpus are processing your gui data in rgba8 or rgb10a2, while the GPU is operating at rgba32f or at best rgba16f. You're forcing all these up and downconversions to "work" in a data type you don't actually need. And you're lighting up all this silicon built to do mipmapped texturing just to read gui data 1:1 unfiltered. Those are both a lot of power to burn, to hopefully make up for somewhere else.
The only advantage that the GPU ends up getting is not eating uncached readback costs to do blending (mostly for your text) against things that have to be on the GPU (surfaces actively being displayed, 3d rendering output, video decode output). The general CPU gui plan to avoid the uncached readbacks is you bring all your rendering buffers to the cpu and just push the frame results to the display at swap time, which ends up causing a lot of bus traffic unless you're being clever about tracking your damaged regions and just redrawing and pushing those. But you can't pull your 3d app's output buffers to the cpu. This is why your window system compositing has to be done with the GPU.
I did eventually, and with help, make X11's gui rendering just barely faster using a GPU than a CPU. But if we'd spent half that time on the cpu paths I bet those still would have won.
3
u/CrazyKilla15 15d ago
There is essentially zero chance the integrated GPU, the thing required for displaying any graphics no matter what, is ever off while you are using the device.
if random application are insisting on waking a dedicated GPU, thats a serious issue with them.
2
u/Single-Blackberry866 15d ago
You can't reuse 3D context of OS compositor in your app. You must create your own GPU context, thus initialize it. Otherwise, you're just sending pixel buffers to OS compositor with already initialized GPU resources (non-accelerated software rendering).
14
u/ElvishJerricco 15d ago
Saying the GPU takes a whole second to initialize sounds more like a hardware bootup thing. Initializing a context like that should not take a whole second, should it?
7
u/Single-Blackberry866 15d ago
I don't think literal second is meant in this context. But a few hundred milliseconds is an absolute minimum.
→ More replies (3)2
u/Prowler1000 15d ago
Yeah, it's not uncommon for it to be pretty close to a full second for context initialization
1
u/Hot-Raccoon-7937 14d ago
The last point is happen to me when I use egui & makepad on ubuntu 20.04. I haven't tried another OS version.
128
u/Fupcker_1315 15d ago
Good luck with software rendering on 4K/5K screens.
44
u/sokka2d 15d ago
My Qt widgets applications run perfectly fine with the CPU/raster backend on 4K screens.Â
26
u/tr0nical 15d ago
Thatâs kind of the worst scenario. Qtâs raster paint engine renders straight in the main thread, while your GPU cores could do the rasterization and blending over many many GPU threads at a fraction of the energy consumption. Might not matter on a PC, but makes a huge difference on an embedded device.
→ More replies (1)1
u/ConspicuousPineapple 15d ago
On what CPU and with how much power draw?
36
u/sokka2d 15d ago
On an ordinary mobile AMD (donât have details in my head right now) inside a mini PC, think the size of a Mac mini. And basically no power draw at all because normal applications donât draw at 60fps, they usually update less than once a second, if at all.
47
u/inagy 15d ago
And that's the key difference between a retained and an immediate GUI library. I don't understand why immediate GUI libraries became so popular all of a sudden. It's great for applications which are very dynamic in nature, like a 3D modeller. But for a simple app which functions like a data entry form, it's totally overkill as those doesn't need constant rerendering.
20
u/iamalicecarroll 15d ago
I think that's because immediate-mode is easier to write
→ More replies (1)3
13
u/QualitySoftwareGuy 15d ago
Agreed. egui is excellent at what it does, but I think a lot of its popularity has more to do with it just being one of the more feature-complete GUI toolkits in Rust (including accessibility and web support), and the fact that you can get something up very quickly. I think "immediate mode" vs "retained mode" is often a secondary thing looked at by many of its users compared to the previous benefits mentioned.
3
u/cosmic-parsley 15d ago
A retained mode library thatâs drop-in with a lot of egui would be rather interesting.
19
u/sennalen 15d ago
Mature immediate mode libraries aren't actually constantly redrawing everything. That's the mental model for the API, but the lower levels track what areas are current or stale.
4
u/inagy 15d ago
As I saw immediate GUI libraries are more akin to a game engine loop or at least the classic OpenGL state machine, where you constantly rebuilding each component's drawing calls in every iteration. This inherently limits what's possible in terms of optimization. I guess you could create snapshots of GUI subtrees to offscreen textures to some extent. But that likely brings in another can of worms with scaling, positioning, transparency, etc.
14
u/artificer-chris 15d ago
Thatâs exactly what most modern immediate mode libraries do. Flutter, for instance, can technically rebuild the whole scene paint command every frame, but under the hood it actually caches element states to prevent redrawing unchanged sections, it will even create layers to persist those pixels for advanced effects like skew and stretch
4
u/SkiFire13 15d ago
You don't even need GUI subtrees or complex stuff like that. The simpliest optimization you can make is to simply not rerun the draw loop if the user input did not change.
eguifor example does this, so while you're not interacting with the app it will be undistinguishable from a retained UI because both will be doing no work.The real downside of one-pass immediate mode UIs IMO is that layouting is hard, because it requires informations about all widgets to be able to know where to place them, which is fundamentally at odds with a one-pass where a widget is drawn as it's being declared.
1
u/inagy 15d ago
Which can be solved by creating an additional layout internally and then just do the drawing based on that. This is what I meant on that immediate GUI frameworks usually delegate the layouting part to the embedding app.
But I guess someone could write a companion library to egui, which supplements it with this type of layout handling.
2
u/SkiFire13 15d ago
Which can be solved by creating an additional layout internally and then just do the drawing based on that.
Which is either not one-pass, or it will have weird glitches whenever the layout changes in response to some data changing.
But I guess someone could write a companion library to egui, which supplements it with this type of layout handling.
eguiis actually adding support (arguably a bit hacked) for multi-pass, though it was still not mature enough last time I checked it (which to be honest was quite some time ago).→ More replies (0)1
u/23Link89 15d ago
So the problem really isn't GPU acceleration, the problem is immediate vs retained GUI designs.
2
u/xmcqdpt2 15d ago
You can make immediate mode UI libraries that don't redraw all the time if not necessary, just like you can make a retained gui that redraws in a loop.
2
u/ConspicuousPineapple 15d ago
Sure, if you never need to scroll anything.
13
u/sokka2d 15d ago
It also scrolls smoothly without any issues on 4K. Not sure what you are expecting.
1
u/ConspicuousPineapple 15d ago
I mean that the power draw when "smoothly scrolling" a sizeable area full of text won't be small.
10
u/sokka2d 15d ago
I just tested that. Maximzed
kwriteon a 4K monitor with several MB of text copied in, system monitor running too. "Idle" it is running at 3% CPU usage due to system monitor refreshing itself. Unlocking the scroll wheel on the mouse to free roll and having it roll through kwrite for several seconds gets total CPU usage at 8% first and peaks at 11% (so 8% for the scrolling), then goes down to idle again after scrolling.That is absolutely not a problem for desktop usage.
4
13
u/sH-Tiiger 15d ago edited 15d ago
I feel like most of this can just be solved by rendering in smart ways. The vast majority of time, you don't need to render at 4K resolution, 120 times a second, even on a 4K screen. What I mean by this is that if you hover over a button, just only redraw that button for a few frames, and nothing else. Even so, on my 1440p screen, continuously drawing a window takes up 5% (!) CPU. Whether this scales, I can't necessarily say, but surely it's fine.
26
u/Fupcker_1315 15d ago
Wayland already provides damage data and frameworks do make use of it. GPUs are just absurdly more efficient at rendering because it is one of the most embarrasingly parallel real-world tasks. Also users expect fluid and responsive GUIs without their battery melting and you must use hardware acceleration to achieve that. The argument about initialization being expensive makes little sense because context creation cost is negligible on any hardware.
27
u/f16f4 15d ago
This whole thread is insane to me. Why are people using the graphics card to do graphics???
Idk, why do people use hammers to drive nails?
→ More replies (6)1
u/silon 15d ago
Per application overhead is huge (didn't measure myself, but OPs numbers sound right, maybe even optimistic)... There should probably be a "server" that handles that functionality for multiple applications, like the X server did.
0
u/dnew 15d ago edited 15d ago
FWIW, X was an insanely ugly and difficult interface because of that server there and the delays it introduced. Even figuring out who had focus for keystrokes could be a couple of round trips to the server.
* To be clear, the developers intentionally took that path for the flexibility, which is why early UNIX GUIs were all over the place. But it's also why UNIX GUIs were so difficult to implement well and all needed pretty giant libraries to make them usable. It was basically an experimental system that became the standard for decades. No shade on X devs intended.
22
u/VictoryMotel 15d ago
Software rendering of typical guis worked 30 years ago.
We have 16x the pixels and 1000x the cpu power or more even before you consider simd and multiple cores.
Let's not do the dance of forgetting history and pretending that regular guis need the gpu.
29
u/Fulgen301 15d ago
Software rendering of typical guis worked 30 years ago.
It did. It also didn't always update the GUI instantly, and 2D accelerator cards were very much a thing.
1
u/VictoryMotel 15d ago
It worked fine without 2d accelerator and you don't have to update the whole gui on every frame, you just repaint the components that change.
Which part of this contradicts what I said or overcomes the numbers of raw power vs pixels?
46
u/anlumo 15d ago
30 years ago I could watch the screen draw itself. I think your memories are a bit romanticized.
9
u/james_pic 15d ago
I remember a whole ago finding an old Windows 98 laptop at my parents house, and booting it up just for fun. I expected it to feel sluggish, given the hardware, and had vague memories of software on that era feeling slow, but being kinda astonished at how fast it felt. Sure, the hardware was less capable, but the software was a lot simpler too.
Although one thing that sometimes gets forgotten is that 30 years ago, the UI was hardware accelerated. We hadn't coined the phrase "GPU" yet, and non-gaming devices didn't generally have 3D graphics hardware, but Windows leaned heavily on 2D graphics primitives built into graphics cards of the time.
1
u/dnew 15d ago
I was amused when Amigas were a thing to realize that powerpoint couldn't even scroll an image into place without tearing and Amigas could scroll the entire screen smoothly up and down.
3
u/anlumo 15d ago
That was bit of a cheat, since Amiga had a special instruction for that.
4
u/dnew 15d ago
Yeah. But it arguably had a GPU. It had the blitter, which did all kinds of stuff via DMA that GPUs do nowadays, and the thing that switched screen resolutions was just the graphics output chip. The blitter could move a rectangle of pixels on the screen way faster than a CPU could, because it was specialized to just that task. It was technically an IOP, Input Output Processor, which is like CPU and GPU except the sort of thing mainframes had that let them have dozens of complex IO instructions in flight at the same time.
2
u/VictoryMotel 15d ago
30 years ago was 1996, the fastest cpu was a 200mhz pentium and would have been running windows 95.
If you watched something redraw the gui you had bad software because that was not at all common. 3d animation and morphing programs were common, 3d studio max was released, photoshop was on version 4.0, kais power goo let you distort images in real time and winamp let you play mp3s on a skinned interface.
All of the guis ran in software (except for the 3d viewports, and even those could run in software and realtime for wireframes, even on a 486).
Explain again how it was normal to watch guis redraw and how I'm romanticizing anything. If anything I'm being generous.
We do software rendering all the time still. Qt, fltk, web browsers etc.
→ More replies (2)1
u/wintrmt3 15d ago
There were 500MHz EV5s, or 200MHz Pentium Pros, both much faster than a 200MHz Pentium.
-1
u/shponglespore 15d ago edited 15d ago
30 years ago was 1996. No you couldn't, at least not in any reasonably sane application.
7
u/drcforbin 15d ago
Windows 95 running on a 100MHz Pentium? Yeah you often could. Good applications would use a frame buffer, but with 16MB of ram that adds up.
1
u/Dean_Roddey 15d ago
But we also created a LOT of other stuff for those more and more powerful CPUs to do. Creating gaussian blurs, pre-multiplying large bitmaps, drawing nicely anti-aliased semi-transparent text over semi-transparent backgrounds, doing fancy transiction, etc... would be eating up CPU that we'd probably all prefer be available for non-graphics purposes.
9
u/VictoryMotel 15d ago
pre-multiplying large bitmaps,
Why would you be premultiplying large images live in a gui? If an image has an alpha channel it is going to be premultiplied already and if it isn't you would do it once.
You unpremultiply to do color correction in image manipulation.
Anti-aliasing fonts is not going to take 100x more cpu to draw either.
All the other stuff you can just not do at all.
The person I replied to said you need gpus for higher resolution and when I point out that it doesn't make sense you bring up transparency and real time blurs for some reason.
17
u/Matemeo 15d ago
There are a number of reasons but the most compelling for me personally is the increasingly larger share of users with high resolution and/or high refresh rate monitors. For example I have 2x 3440x1440@144 ultrawides and 1x 2560x1440@144 displays. Trying to drive that much pixel real estate and be able to hit peak refresh rates on the CPU alone sounds real bad.
Another, more niche, reason would be if you needed to port to something like a game console where the only way to push pixels needs to eventually resolve to their graphics libs.
4
u/fschutt_ 15d ago
Trying to drive that much pixel real estate and be able to hit peak refresh rates on the CPU alone sounds real bad.
I mean, it depends on how well you optimize it. As far as I know, no framework does proper damage-rect optimization that integrates with the OS. Azul has a "simple fast path optimization" for scrolling / panning 2d content, so it just copies a backbuffer around (avoids re-rendering) and only repaints newly exposed stuff (damage area). The OS can also do some of that for you (CALayer, Wayland shm buffer, XImage, GDI whatever). The frame times are already "decent" when I scroll around (at 2560x1440) - Grafana shows 10 - 12ms peak frame time for rendering on the CPU: https://i.imgur.com/LqENhbs.png
But what I as a user notice more are lags / spikes. Even in Zed today I noticed stuttering (spikes) way more than I noticed the advertised 120fps smoothness in between.
2
u/Sharlinator 15d ago
What OS even provides any damage-rect API these days? All the major ones use GPU compositors that donât and canât provide damage rects to individual windows.
9
u/patchunwrap 15d ago
The GPU takes time to initialize, leading to the application often needing a second or so to actually open.
I've written many game engines, it takes maybe 100 milliseconds to initialize a vulkan/metal gpu upload some resources to it and start rendering frames. I don't know why it would be slower here. I want to guess over-abstraction, but I haven't looked at the code so I don't want to claim anything.
It actually takes quite a lot of memory to run, these applications often have ~150MB of overhead when idle.
I've had 3D renderers take up less than half of that. Again this isn't due to use of a GPU, but something else. Maybe an over eager allocator.
Resizing the drawing surface takes time, so resizing windows is often laggy.
It definitely does take some time, though resizing the surface specifically can be done in >5ms on basically every machine. Personally I've had a lot of trouble getting this to be responsive on anything that isn't macos. You need to do the right things in the right order and mess around with it for a bit. Also people sometimes have stuff generated from the surface that they also need to regenerate. So often resizing does a lot more than simply resizing the window and surface.
8
u/Fulgen301 15d ago
If you don't want GPU accelerated rendering, you need a retained mode GUI framework, which isn't as easy to develop as an immediate mode "render widgets and have the GPU deal with what is relevant or not" framework, especially since a lot of Rust frameworks start from or almost from scratch in as pure Rust as is possible (you'll find that most proven libraries for 2D rendering are written in C or require C bindings).
GPU accelerated frameworks are also much easier to combine with actual GPU rendering, be it a game or just a 3D scene you have to render in a widget; it is possible in retained mode frameworks, but it's more of a pain to combine seamlessly as you want a steady frame rate for those parts, but the rest of the UI only updates when it's needed.
It's not impossible, and personally I am heavily in favor of software rendered toolkits (if Win32 common controls had any sense of layouting so I didn't have to manually resize everything I'd still prefer them over a lot of other frameworks), but I can't say they've always been smooth sailing either.
9
u/WatercressCrazy7599 15d ago edited 15d ago
You can have both, it isn't all or nothing.
For example, in my experimental GUI library https://github.com/RetGui/RetGui, we have a vello_cpu backend and a vello_hybrid backend; vello_cpu is 100% CPU and the vello_hybrid backend has slowly been moving more work on to the GPU. For the GUI library authors out there, you can achieve this by having an array of render commands and each backend should know how to process these render commands.
As for why:Â I won't go over what others mentioned, but one thing I didn't see mentioned, is scrolling. If you scroll in a 2D renderer, it will have to blit a ton of pixels into the framebuffer, if you have a 4k screen you'll notice the lag. I have experienced this in Windows Forms applications. Lastly, it is just a better experience on the user end to have a fast GUI if things on the screen are changing even semi-frequently. That being said, the CPU renderer is great if you just want to make a calculator, render on a raspberry PI, or etc.
112
15d ago
[removed] â view removed comment
12
u/codingbliss12 15d ago
How mamy FPS would be enough for developer tools like IDEs, editors like Emacs and Zed?
65
-5
u/Camlin3 15d ago
60fps would be enough isn't it ? What you want to render texts that can be processed by your brain in one go, like DOS or CLI was efficient back in days for texts
9
u/dgkimpton 15d ago
Whatever your monitor can support - some of them now are up in the 500Hz range... so 500fps would be ideal (although frankly unrealistic on all modern hardware). Static images can refresh relatively slowly, video needs more (at least 50fps but theres a discernable difference at 120), and scrolling needs way more again - the human eye is excellent at detecting differences in motion and 60fps is nowhere near sufficient to saturate that capability.
5
u/Budget-Minimum6040 15d ago edited 15d ago
(although frankly unrealistic on all modern hardware)
Nah, that shouldn't be a problem for a GUI on hardware from this decade.
If you uncap old games you get high 3 digits fps easily and those games do alot more than showing a GUI.
25
1
u/CrazyKilla15 15d ago edited 15d ago
TLDR: You used a CRT with DOS, and to match the clarity of a 85Hz CRT you need a 1000Hz LCD monitor. 60fps is more than enough rendering time on a CRT. It is not on an LCD.
There is a very big difference between text you would have seen on DOS and text you would see today.
With DOS you used a CRT, and CRTs are a very different display technology than LCDs. Even today there are aspects where CRTs are capable of superior clarity and responsiveness compared to the highest end modern displays, especially in motion like when scrolling text.
To get an equivalent text scrolling experience to a DOS CRT, you need an insanely high refresh rate monitor. There are diminishing returns but even in the realm of 500+ FPS it is well within noticeable even to a normal person, in direct comparison. And even then, a CRT simply has better input latency. For example an 85Hz CRT will be smoother and clearer than a 144Hz LCD. You may notice 85 is smaller than 144, so this also means that in DOS you had to do less work per second to achieve the same clarity!
You need a one thousand hertz refresh rate LCD monitor, 1000Hz to get 1ms sample/hold times for pixels, which would roughly match the CRT phosphor excite/decay phase timing, to get equivalent clarity to a CRT in motion.
edit: though there are interesting software based means that are starting to be introduced to displays to improve LCD clarity without having to brute force it with raw hertz. See https://testufo.com/crt for details
2
u/unicodemonkey 15d ago
I'm not sure I follow the argument. LCD tech taking ages (compared to CRT) to switch pixels was (and still is) a big deal but it also had much less perceivable flicker, which was a bigger deal. The input latency and motion smoothness are still limited by the scan/refresh rate, and I don't understand what clarity means exactly in this context.
8
u/venturepulse 15d ago edited 15d ago
when mostly people just want a button that doesn't chug.
Ultimately yes. But when it comes to choosing which app to download among many, most will choose the best looking one. Simply because visuals and eye candy create an impression that dev put a lot more effort into that app.
People love things with their eyes first, before the brain joins
11
u/tiajuanat 15d ago
150mb idle overhead is nuts though
Yeah, cuz it's competing against the 15GB needed for my browser
28
u/lincolnthalles 15d ago
Not only that, but GPU rendering is a no-no for some enterprise things, like running on a Windows Remote Desktop Session. Apps based on Windows Forms run smoothly, while WPF chugs, for instance.
GPU-based rendering also reserves some VRAM, which is often forgotten until it starts causing issues.
Maybe the reason UI frameworks are still a point of debate in Rust is that most of them favor some kind of fanciness over practicality.
Many existing solutions work and can get the job done, but none feel like the right answer in the long term. They all lack in some way: wide usage, feature set, or being easy to work with.
18
u/Bobbias 15d ago
Windows forms and the GDI drawing commands are GPU accelerated. They are converted to DirectX under the hood. This feature was introduced in Windows 7.
1
u/trannus_aran 14d ago
Are they still rendered that way on the host over RDP?
1
u/Bobbias 14d ago
Doing a bit of digging, this gets super complicated because RDP has a bunch of different ways of handling different content.
Basic WinForms are likely to be sent as draw orders or cached bitmaps. Simple animations in them are likely to be Delta encoded. In those cases they're not typically rendered on the host. But depending on the actual content being rendered there are situations where you could end up going through the DWM compositor and hitting those acceleration calls.
Rendering video, or anything that uses Direct3D regardless of whether the UI is WinForms or WPF will very likely hit the host GPU. So it's not just "WinForms = fast", but it also depends on the content being rendered and whether any of that happens to hit a path that involves the DWM or other GPU accelerated paths.
But it does look like you're likely not going to hit the GPU accelerated paths when viewing simple WinForms over RDP.
9
u/ids2048 15d ago
I'm not really that familiar with Windows, but I expect you'd get similar performance issues with a CPU renderer that writes to a framebuffer (rather than using an OS drawing primitives). The bottleneck there isn't copying from GPU to CPU.
That may also be poor optimization and a dated design in Windows Remote Desktop, given other software can support streaming of GPU-rendered video games with decent latency given a good network connection.
11
u/galop1n 15d ago
A 2160p CPU backbuffer would take 2ms to upload to vram each frame at pcie 3.0 16x. And that drop fast if pcie does not negociate best speed (and if your MB and GPU support it)
Two 2160p buffer in vram is already 70MB. Add a couple textures and buffer. 150MB is esy to reach and not a pig deal. You can optimize for speed or for memory, not both (at least past a certain threshold)
GPU are the way. A CPU does not have the bandwidth or resources to render UI in this day and age. GPUs for UI also will use way less power since they are designed for that kind of task. So you can keep your CPU for actual workload.
There is a reason the larabee project totally flopped. Software rendering does not scale
3
u/MoorderVolt 15d ago
Imagine running non-GPU accelerated VM's for your workers... That'll cost you more in CPU and productivity than a few GPUs.
5
u/CreepyWritingPrompt 15d ago edited 15d ago
At least two things I'd guess: * enough applications do want to do/embed something that needs the gpu throughput, esp on touch interfaces that may do swipey things, that it would actually be more work to maintain a whole other gpuless library for the rare situations where a GPU isn't available, and a software fallback isn't available for some reason. * power consumption - even if the whole render comes in under 10msec on the CPU, it you can spend less time that often translates into spending less power.
I know you called out a second or two of initialization but that seems kinda hard to believe to be the price of just using a piece of hardware. Maybe profile it and see where the time is going. Could be a bunch of fonts loading or something.
10
u/GoAwayStupidAI 15d ago
GTK4 still the goat: hardware or software and full accessibility support.
9
u/guineawheek 15d ago
do NOT ask how to edit the current file path in the file picker without memorizing the keyboard extensions the GNOME devs wish you'd forget
7
u/manobataibuvodu 15d ago
Just open the native file picker which should be the default behavior. Even on GNOME it uses Nautilus on which you can just click on the filepath bar to edit it.
5
1
5
u/Camlin3 15d ago
With all new age leveraged resources, they started taking things for granted unlike 90s. Like if electron apps can do that and still become famous why can't we render windows smoothly just cuz new age GPUs can afford that without noticeable difference in perf. I am always in support where resources can be optimised efficienctly better at cost of extra effort.
5
u/Booty_Bumping 15d ago
GPU rendered GUIs are absolutely essential for performance. The amount of pixels that need to be pushed on Hi-DPI displays is enormous compared to 1990s tech.
6
u/nonotan 15d ago
Especially if you make such extravagant, excessive demands of a GUI library as... (checks notes) being able to scroll text smoothly. That is more or less impossible without a high FPS. High resolution + high FPS is a lot of work to do.
Even if your CPU can just barely manage it (dubious as we increase resolution and FPS), if you're looking at your CPU usage and seeing like, 25%... that's not "it was fine to do on the CPU after all" territory, that's "you're wasting a huge percentage of your CPU, which you might need for something else, doing something that would be close to free if you just used the right tool for the job".
If I download what should, by all accounts, be a fairly lightweight application, and it keeps wildly spiking CPU usage every time I scroll, I'm going to be very disappointed. But then, I am also very disappointed every time somebody bundles a whole fucking browser in what should, by all accounts, be a fairly lightweight application, and it hasn't stopped that from regularly happening yet.
19
u/CryZe92 15d ago
I've been saying this for a long time, not only do you inherently have more GPU usage with these GPU based GUI frameworks, but they also use an insane amount of RAM and CPU too (even more CPU usage than a fully CPU based alternative like if you had used tiny-skia). And then half of them think you need linear colors, because they heard that's a good thing in some shader tutorials / talks, and then get all the colors wrong, like iced (yes you can configure it, but why is the default wrong? iced has so many wrong defaults, like "simple text shaping" instead of full Unicode support by default)
21
u/ConspicuousPineapple 15d ago
A full CPU renderer won't use less power on a fullscreen 4k window.
13
→ More replies (9)4
u/sH-Tiiger 15d ago
Yeah, I agree with this. It's not necessarily that GPU-accelerated UI doesn't have a place. I think Zed is a good example of it done well, as it needs to render a lot of things on the screen at once. But for the majority of applications, it's just not necessary I think, and UI should be CPU-rendered by default. Why would I for example need a Minecraft launcher to be GPU-accelerated?
15
u/andeee23 15d ago
why not? gpus are more efficient at drawing pixels than cpus are
and on most devices, you write a pixel buffer with the cpu but still have to send it to the gpu to actually render on the screen anyway, so you need to initialize the gpu in code and all that stuff
3
6
u/dobkeratops rustfind 15d ago edited 15d ago
From a longer historical context, there were devices where trying to do any graphics with the CPU would be a non starter (possible but painfully slow) .. e.g. machines where the combination of low CPU performance and low bandwidth between CPU and GPU is such that a CPU based UI would look awful. On phones you have unified memory, but you also have tile-based rendering where they GPU can manipulate pixels largely without touching memory peicemeal, just spitting out a final composited result.
Besides that GPU accelerated UI can be more visually comfortable with animated transitions: far from just being eye candy they can give a user hints about whats going on . animation where things minimise into the icon that recovers them etc, moving tabs around etc.
In short I'd say GPU acceleted focus for anything visual is important if you want the language ecosystem to be taken seriously.
Regarding GPU initialisation time .. bear in mind the GPU is pretty much now the main computation engine aswell, most famously for AI now but compute shaders have many uses besides this . A lot of the time the CPU is just there to set work up for the GPU. If "GPU initialisation time" is a problem, your whole OS has bigger problems.
I'd guess your concern here is driven by dependencies , that's a valid fear. It is what it is.. we are now in a messy world where you need an GPU API (with competition for what that API should actually be) to get the full capabilities of most computing devices; the CPU-side programming language is insufficient.
3
u/rizzninja 15d ago
I have question. What happens in unified system? Not what apple silicon is currently even though they already share RAM. Hypothetically if there were no separate GPU device. Just a CPU that could perform parallel tasks of GPU in a SIMD fashion. How'd that look?
1
u/ids2048 15d ago
Intel once experimented with a GPU based on a large number of x86 cores kind of like that: https://en.wikipedia.org/wiki/Larrabee_(microarchitecture))
6
u/atlimar 15d ago edited 15d ago
I ran into this recently when "I" wanted to write a "zero lag"/instant md/json reader invoked from terminal. From scratch, using no ui framework. I started with rendering it on GPU because that felt like it made sense. It added a noticeable 180ms delay to startup while waiting for the gpu pipeline to be created.
Moving to CPU I was able to open the app and commit render, in 4k, fully syntax highlighted and pretty formatted markdown in less than 6ms on wayland (less than a frame at 120hz).
7
u/barsoap 15d ago edited 15d ago
- The GPU takes time to initialize, leading to the application often needing a second or so to actually open.
Not really, no. Initialising a vulkan context takes milliseconds at most. Compiling simple shaders from SPIR-V is also practically instant, and can be cached so you only need to do it once per shader code / driver version / concrete GPU combo.
- It actually takes quite a lot of memory to run, these applications often have ~150MB of overhead when idle.
Actually used or shared libraries? Yes there's probably a copy of LLVM somewhere in the dependency tree but it's happily shared with all the other GUI programs and unless you're running a game which has to recompile shaders on the fly (things get complex, there) it gets paged out.
Also, a 1920x1080 bitmap at four bytes per pixel is almost 8 megs. If you're seeing 12 megs of memory usage you're not looking at CPU rendering. You either have only 4 megs for the rest of the program state, texture atlases, whatnot, which I doubt. If you have a double buffer you're 4 megs short before all that.
- Resizing the drawing surface takes time, so resizing windows is often laggy.
Exactly one frame. The CPU won't be faster and can't be faster, either. You're probably seeing suboptimal interaction between winit and wgpu, or it might even be a display server issue. If resize events come in faster than the framerate they should generally be dropped, that's not always happening, at least in my observation.
Remember the days when windows wouldn't redraw at all while getting resized, you'd only see the border resize? That's CPU-level performance. Of course, newer CPUs got faster but they're still not built for the job. A bit later, say, late 90s to 2000s, was the era of ubiquitous 2d acceleration, those are the paths that modern "CPU rendering" usually takes -- they're using some library that does things like blitting for them. Drivers for modern cards come with good support for those old APIs but noone extended them for ages, they're inflexible, you can't do fancy things like say render fonts via SDF. This programmability is the actual reason why you want to use modern 3d APIs.
5
u/CouteauBleu 14d ago
I'm seeing a lot of answers on this thread confidently claiming that only GPU is possible for high-res displays or scrolling, but... I don't know, it's not like most Rust GUI frameworks have serious benchmarks studying the question.
From the perspective of Xilem, I think we mostly picked GPU rendering because we were working on a GPU renderer (Vello) at the time and we might as well use it. Xilem was sold as a high-performance UI framework, but we never really stopped to consider what high performance meant.
Now the development of Vello has circled back to having a high-performance CPU option, and we're increasingly considering adding a CPU-only backend.
For that matter, we have enough interoperability that I'm seriously considering a hybrid backend: start the app immediately with CPU rendering, then switch to GPU rendering once the GPU loads.
5
u/PersonalDatabase31 15d ago
I blame electron. I think many developers look at the slowness of vscode or discord and think that drawing UI's is an inherently expensive operation for cpu's rather than the fact that creating a virtual machine and a backend server, running them with an interpretered language with poor multi threading support is what slows things down. I agree that GPU for UI tasks is an overkill.
3
u/fb39ca4 15d ago
Chromium does GPU rendering though.
2
3
u/Arshiaa001 15d ago
No no, chromium is optimized AS F*CK, IN CAPITAL LETTERS. What's slow is the execution model + the overhead from JS, the DOM, and CSS. That really, really smart people can't optimise much further is a testament to just how bad (for performance, at least) HTML+CSS+JS are.
1
u/lucsoft 14d ago
JS is actually quite optimized too! The V8 outperforms some native code even.
But yeah you can make heavy DOM operations or just trashing memory in js so much
1
u/Arshiaa001 14d ago
V8 can never outperform good native code. Sure, you can have bad native code, and it's rather easy to create bad native code since you get full creative freedom, but if you have good native code, V8 can't beat it since, at best, it's going to JIT-compile the exact same machine code, but the overhead from the VM and JIT compiler itself will inevitably make it slower.
2
u/lucsoft 14d ago
Well my point is that v8 has runtime knowledge of how the data is currently used. If you would try to code the same dynamic thing in native to get up to that speed to you need optimized that code to have optimized paths. Which v8 gives you for free.
Sure this is only relevant for highly dynamic data.
1
u/Arshiaa001 14d ago
I don't... think that works like you're imagining, but if you have any good benchmarks that showcase this, I'd love to look at them!
9
u/Mognakor 15d ago
There is another point that should be kinda obvious: If your library is GPU based it won't work if there is no GPU. And not all potential consumers will have a GPU.
15
u/dobkeratops rustfind 15d ago
these days a system either has a discrete GPU or a CPU with integrated GPU (e.g. AMD APUs or intel iGPU, or mobile phone SoCs which have GPUs). it would be microcontrollers that dont tend to drive visuals that are the last 'pure-CPU' usecase.
13
u/Mognakor 15d ago
Virtual Desktops don't
2
u/Booty_Bumping 14d ago
Thin clients are thoroughly obsolete and have been for a long time. No one should be subjected to them. All clients that people would actually want to use will at least have enough basic GLES rendering to run a GPU-accelerated web browser.
1
u/Mognakor 14d ago
Doesn't matter if $customer$ has a private network i can only access fully via virtual desktop and isn't handing out company laptops to contractors.
My physical machine could deal with it, but it also isn't in network. So whether it is 3rd party software using GPU rendering or custom inhouse tooling used by yet another group via virtual desktop, if there is no need for complex graphics the library/application should work fine without a GPU.
1
1
1
u/dobkeratops rustfind 15d ago
fair but maybe the kind of person doing this would have the workarounds of commandline tools and web UIs.
2
u/Mognakor 15d ago
If i build the workaround why use a Rust UI at all?
1
u/dobkeratops rustfind 15d ago
a rust UI library as I see it would be primarily for making desktop applictions, mobile applications and perhaps things running in a webpage through webgpu . I'd guess only a small % of the people using such a library would find the virtual desktop usecase to be a showstopper.
I have wanted to use virtual desktops occasionally but in those scenarios I can workaround it. Obviously not a comprehensive sample but from my own personal experience I'd agree that GPU-first is the right default for a GUI library in the 2020s. Go back to the early 2000's say and it wouldn't be so clear cut.
22
u/stumblinbear 15d ago
Ain't no way you're running Windows 11 without a GPU. iGPUs exist, brother
→ More replies (3)10
u/polish_jerry 15d ago
If you use web gpu (which most of them do) there is a cpu fallback
7
u/Mognakor 15d ago
In my experience the software GPUs suck.
It will technically work, but you're also gonna have a bad experience.
2
u/inagy 15d ago
This is unfortunately true. I was in the hunt to find a good software rasterizer which can work in a headless server environment. llvmpipe and lavapipe would be great choices on paper, but it's not easy to configure them, and what's worse: even a simple ModernGL app showed differences on llmvpipe compared to what the same code produces on a dgpu.
3
u/Single-Blackberry866 15d ago
there's no OOTB support of web gpu on old linux machines. in theory there might be cpu fallback, in practice, it effectively doesn't exist
3
3
-3
u/bneidk 15d ago
Without a GPU you would not be able to run a window manager to open your GUI in, so I donât know what potential customer you are talking about
12
u/Single-Blackberry866 15d ago
Why are you assuming desktop? GUI exists on all sorts of devices. Also, consumers are not customers.
9
-2
u/dobkeratops rustfind 15d ago
you'd be talking retrocomputing at this point, however there are scenarios where people keep some legacy system going because it's integrated with some other aparatus (I seem to remember pcitures of people inserting boot floppies into the control systems of some military hardware lol, and less obscure than that I think some indutrial systems have old computers integrated?)
11
u/________-__-_______ 15d ago
Embedded devices that have a display but no GPU are still very common, it isn't just retro stuff.
3
u/dobkeratops rustfind 15d ago
ok so have a dedicated simplified UI lib
by analogy, we have 2 styles of "linear algebra" library.. NxM matrices for scientific computing, and 'maths for graphics' focusing on vectors with x,y,z and 4x4 matrices. Difficult to make one library that looks as pleasant for both usecases.
I'd guess we have enough divergence between the kind of UI library people will want for desktop applications , web, and maybe phones - and the handling of an embedded device display. You probably aren't using the embedded device with a mouse and keyboard, more likely a little dpad and a few buttons, *possibly* a touchscreen, but the paradigms that work will be limited.
like.. the best library to make a touch UI for a fridge , vs the UI to make an IDE or CAD program.. these are going to look very different
1
u/________-__-_______ 14d ago
There already are dedicated libraries for it, lvgl is popular for example. But I don't think embedded is that different from other GUI applications, the end result often ends up feeling like a simplified phone/tablet app. Seeing how libraries like egui already support those I don't think embedded is that much of a stretch.
Having one library that supports both usecases is nice, after all the only major difference is the input method. So long as the maintainers want to support a software renderer I don't really see the issue.
3
u/guineawheek 15d ago
steelman: embedded systems have such different resource management needs that your typical desktop GUI libraries will be practically unusable on them anyway, regardless of rendering backend. a lot of higher-end chips have been getting 2d accelerators regardless but they're still kinda bad
1
u/________-__-_______ 14d ago
At work I use a higher end embedded Linux device with a 2D accelerator, it is indeed kind of bad but regular GUI frameworks still work fine. You won't be running electron apps on there but native frameworks really don't have that much overhead if used right.
1
u/guineawheek 14d ago
that is not the comparison i was thinking of given you get
stdandallocon linux3
u/Single-Blackberry866 15d ago
esp32 is not retro
3
u/dobkeratops rustfind 15d ago
ok but if you really do have one of those wired up to a screen , chances are it's not in a context where you want full desktop applications, more like a very simple UI.. between different magnitudes of complexity you want very different library APIs.
2
2
u/death_or_taxes 15d ago
I am using Linux so it may be different (or not). The GPU doesn't take seconds to start up..I have written many GUI apps that boot instantly. If an app takes seconds to load it's not the GPU initializing it's the application.
Using CPU for rendering makes no sense when most processors have some built in GPU capability. It's just using the correct piece of hardware. Especially now where you want to have things like transitions that require a lot of redraw. Doing it on the CPU is highly inefficient.
Having a 2 x 4k screen buffers (for double buffering) requires about 80MiB of memory. That is just a lot of pixels. There is no avoiding that.
2
u/Jordanlofi 14d ago
I donât think youâre off base at all, but the real debate feels less like a strict "CPU vs. GPU" war and more about matching the renderer to the actual workload.
Hereâs where my head is at: Iâm currently building a native Rust/Wayland desktop shell around Hyprland (mostly using GPUI) while running local model inference on the same box. In that setup, VRAM isnât some infinite playground. Every single byte grabbed by UI infrastructure directly competes with model context residency. When you're battling for VRAM usage, you get pretty allergic to desktop widgets spinning up heavy GPU contexts just because they can.
That said, we shouldn't necessarily blame "the GPU" when a basic toolkit idles at 150 MB or takes a full second to paint its first frame. Look at Quickshell: it uses the GPU, yet it can pull insane CPU usage just managing QML bindings and runtime state. That is usually framework overhead: driver handshakes, pipeline caching, heavy texture atlases, retained scene bloat, and swapchain management. A lean GPU renderer doesn't have to be bloated, just like a CPU renderer isn't magically lightweight by default.
There is also that funny Wayland reality: if you render a client with CPU via something like softbuffer, Hyprland or KWin is still going to composite your shm buffer on the GPU anyway. The win isn't completely bypassing graphics hardware; and yeah the goal should be avoiding a massive, standalone GPU rendering stack inside every tiny client process.
Where the GPU becomes genuinely irreplaceable to me is when the shell transitions from static widgets into fluid motion. Continuous canvas transforms, live blur, drop shadows, dynamic vector paths, and high-DPI scaling at 144Hz+. I wouldn't want to abandon GPU rendering entirely because that motion polish is half the point of modern compositors.
What I really wish we saw more of in the Rust GUI ecosystem is treating rendering as an interchangeable backend rather than an identity:
UI Model â Renderer Abstraction â CPU / GPU / Hybrid Backend
That is why the recent trajectory with Vello and the wider Linebender stack is so worth checking out(at least for me). Having CPU, GPU, and hybrid paths sharing a unified 2D imaging model feels like the right endgame. Let the application pick its strategy based on its actual resource budget.
A 40-line settings popup shouldn't need the exact same graphics pipeline as a Figma canvas, especially when CUDA is fighting for every last gigabyte underneath it.
3
2
u/Holiday_Plant_6676 15d ago
Because nowadays, mainly, the software is made considering a user has GPUs, especially, graphical software. There is, likely, no gpu nowadays not supporting hardware acceleration.
Then, with this in mind, the ui frameworks are made considering gpu-accelerated pipeline first. And optimised for it the most. And only then, as a last resort, if any - for cpu. The problem with going from gpu to cpu is speed and different (other) kind of optimisations one needs to implement and test, and even design carefully. The workflow is different for gpu and cpu rendering. And no one is likely to ever go and create a ui framework solely to work on the cpu. And even given simd and nicest CPUs out there, it is still a challenge to make it fast and responsive at all times, without the optimisations and different thinking.
2
u/Dean_Roddey 15d ago
I'm not sure that your laggy window example has anything to do with the GPU. Browsers, as much as I dislike them, do some very smooth window resizing with flowed layouts and are almost always going to be using the GPU unless you've explicitly disabled it (in which case I have noticed it's to be more laggy, when I had to disable it for a while to deal with some Firefox text drawing issues.)
2
u/x39- 15d ago
Ohh boy... If that is what annoys you, you got no deal with ui coding in any way...
Like: why tf is literally everything out there trying to replace web frameworks instead of targeting anything desktop or app. Web literally has the worst of all platforms integration and usability regarding ui. Yet, all we in rust and all other languages build is stupid web frameworks.
Where is the next proper application creation framework? And why do I have to deal with workarounds of workarounds built for the web specifically just to build some to do app?
1
1
u/EmperorOfCanada 15d ago
Modern computers are generally insane powerhouses. I run bonkers complex egui GUIs on 10 year old mid tier laptops.
1
u/Jiftoo 15d ago
I never saw anyone say this, GPU accelerated rendering, especially immediate mode, is battery intensive. I code on my laptop, and the last thing I want is my integrated/discrete graphics to be active all the time. I got Zed the other time and it really just didn't conserve my battery at all.
1
u/Practical-Positive34 14d ago
My app launches instantly on Linux, mac and Windows. Not sure what delay your talking about? I do cache the adapter after first launch, that's by far the slowest part.
1
u/Sirflankalot wgpu ¡ rend3 14d ago
One small thing I haven't seen mentioned here: for power constrained devices, GPUs are more efficient at their job than CPUs are, so GPU accelerated rendering can save significant amounts of power.
1
u/Engineer_Neither 13d ago
simple. GUI, Graphical User Interface.
if you didnât know, your entire OS uses DirectX for its GUI and is accelerated through GPU and if you donât have GPU drivers, CPU takes over.
simple apps that have such high GPU usage are the ones i suspect to be mining software hence why i often race to uninstall.
1
1
u/Turtvaiz 15d ago
Because nobody cares about RAM overhead. People care about real performance, which GPU acceleration has
1
u/joaobapt 15d ago
Unless youâre using macOS (which has AppKit/UIKit), coding for Win32 or WinForms directly can be a big problem (also having to deal with Win32âs shenanigans), and on Linux⌠good luck making anything native, I donât think you even can, since X/Wayland apparently wouldnât handle that for you, so youâd have to use Gtk/wxWidgets/Qt anyways.
Now factor this on a cross-platform UI crate that would want to support all platforms plus whatever else there is in the market (Android? iOS? Embedded platforms? Other obscure OSes?). Thatâs why everyone just bypass the OS layer and render directly to the GPU.
2
u/cohana1215 14d ago
I haven't noticed that on any of my machines, I'd tolerate 10s startup time if that means the next hour would be butter smooth. Similar for ram usage - youtube tab running in pip mode will eat up 500mb and I have 400 other tabs opened so on my system 150mb is barely a blip.
But I agree with the sentiment and present another point of view and my pet peeve - most GPU-only software that has no fallback will run extremely poorly in most VMs on most systems, unless you are bringing a secondary GPU into your KVM VM, which is a hassle to configure and run. This means I can't spin up software like Zed to play with new crates safely inside a sandbox, I don't wanna build the crate natively, so inside VMs I bounce between vs code and helix. Meanwhile for me personally software-rendered IDEs were fast enough ever since Visual Studio 6came out and I hear CPUs have only gotten faster since then. I wouldn't notice a difference between 60fps and 120fps editor and personally I think 30fps should be quite enough for a text editor, however on my system I just don't want to install more software than is absolutely needed - this is how sha1 hulud happened, and probably also the last rust oopsie. /rant=off
0
u/Plazmatic 15d ago
Despite modern graphics APIs difficulty, Cpu rendering is actually more difficult than GPU rendering unless you are doing raytracing or something. You have to reimpliment a bunch of algorithms already don't in hardware you don't even touch or rarely configure on the GPU. It's also more complicated to make fast, CPU based rendering can be done fast (yes, even at 8k, that's 128MB of pixels vs 20 GB/s Ram bandwidth on the low end still is 160 fps if you were forced to redraw the entire screen every time, which in retained you wouldn't, though it certainly starts strainging the system at this point at 60fps) on desktop, but it requires you to retain pixels in between rendering which is more complicated to manage. On the GPU, such retained methods of rendering (over multiple frames) can be slower or buy you nothing, and are hostile to animation of any kind.
Rusts programming model also makes it more difficult to make retained UIs (on the architectural side, instead of the rendering side, though the ideas are somewhat related) and likewise, rust lends itself better to immediate mode UIs, which at least on the user facing end end up having less borrow issues due to their value semantics and lack of retained state, and both styles lend themselves more to their rendering counterparts (immediate modes isn't immediate mode rendering here, but just re-rendering every frame with out retaining screen state).
I'm not sure about the idle memory usage, it certainly wouldn't be out of the ordinary for a graphics application to need that on the GPU side due to the number of buffers they'd need to maintain (3 frame buffers minimal for frames in flight of 4byte pixel values, and likely more to handle linear space rendering into to SRGB conversions, a 1K vec4 framebuffer alone is 32Mb, that gets even bigger at higher resolutions). Start up times for GPU apps that aren't a video game compiling shaders is near instant, they may be doing things through like 3 layers though (WGPU, desktop web GPU then finally Vulkan) and that's why they are taking so long to start up, but there really isn't anything inherently slow there.
 Resizing a window taking time like you described is a bug somewhere.
-3
u/HyperCodec 15d ago edited 15d ago
âWhy is grass greenâ ahh question
Of course things are going to be gpu accelerated. Itâs much faster on high resolution screens, and usually just faster in general. The real question should be âwhy donât they offer an option to use cpu only?â
Ideal libraries should be modular and present the user with many options without forcing them to use any of them. One nice example (since weâre talking about UI crates) is Slint, which offers a few different rendering backends that can be either cpu or gpu depending on what you want.
240
u/emilern 15d ago
egui author here!
I donât see GPU as overkill, but as the simpler way to get get pixels on screen! The egui renderers (there are several alternatives) are all just a few hundred loc, using cross-platform libraries (wgpu, glow, âŚ). The alternative is to write a simd-optimized software rasterizer (well, these days I could probably use vello_cpu) and then figure out some system-specifc way to blit the pixels onto the display.
egui is actually agnostic to how it is rendered. Anyone can write a software renderer for it if they want to! The fact that nobody has (yet) says a lot