Hacker News Reader

Comment by codedokode | Hacker News Reader

Egui is pretty bad idea. It uses "immediate mode" rendering which means whole window is redrawn on every mouse move. I ran PhotoCraft (built in Rust + egui) in a VM wihout a GPU and the UI felt like it was running on 3 fps. If you use egui, try running it without a GPU before releasing.

Egui is definitely not what you want to use on a 4K screen. It is only good for tiny screens of embedded devices.

Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn? (not React, it also re-calculates (but not redraws) everything on every change).

Also why does it visually look like bad version of Telegram? And Telegram can run without a phone present.

View on HN

> Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn?

There's plenty of them. Slint, Floem, iced, Vizia, fltk etc. Slint and fltk in particular also exhibit excellent performance and very little resource usage even without a GPU.

eframe is reactive by default, so it only repaints on input/animation, mouse moves count as input technically though so you get a pass on hover

What is the argument here?

Basically every device has a GPU.

Why is it bad on 4K?

Did you measure anything in a real setup?

>What is the argument here?

it's an incredible waste of resources, especially at high resolutions, to redraw a Gui application like you would a videogame at 60 FPS. These immediate mode UI frameworks were made in particular for that case, to be embedded in real time software, not for a UI where the state is idle or changes only occasionally.

You only redraw when there’s interaction. In exchange you use basically no memory for state retention which frees up the real resource constraint.

Redrawing the whole thing consumes resources. That's power and resources not available to other tasks. There is value in being clever with what you draw.

Yes but it comes at the trade off persistent memory usage. It isn’t just free, and depending on the application in question that may be a lot better trade to make if, say, the app runs in the background or is rarely interacted with.

Moving the mouse is an interaction because there are hover effects.

> Basically every device has a GPU.

Many VMs and remote desktops don't. (Or can't really make use of)

This is an app that connects to your phone and sends messages via the app. I don't think it's that crazy to decide that running on a VM or remote desktop is out of scope.

It doesn't connect to your phone, it just authenticates via the app. I deal with a company where people use thin clients that run WhatsApp on the remote desktop. It's not an unusual case.

Interesting, I apparently skimmed the "Link to your phone" section too quickly (and I guess have a different sense of what that phrase implies than the author of that README, since a "link" that no longer requires the other end to exist anymore doesn't really seem like a link at all).

It is a potentially unsafe app from some random person that can backdoor your computer so it doesn't make sense to run it without a VM.

The argument is that it's wasteful? Even if I had a GPU, I'd rather use it to do inference for insurance rather than drawing a simple UI?

Why do I have to state the obvious like that?

I disagree. First, not every GPU supports Vulkan and other modern standards, and not every GPU even supports executing code. Drivers are often buggy/unsupported. Even if there is a GPU, compiling shaders takes time and CPU must be used in the meantime.

Finally, for app to have access to GPU, it must run on a host unrestricted. Why would you take somebody's code from Internet and run it unrestricted, violating the principle of minimal pivileges? That does not sound smart, especially if you have a crypto wallet on the same computer. Those who do not use VM or sandboxes will sooner or later learn this.

> Did you measure anything in a real setup?

VM is a real setup. Why would I run third-party apps without a sandbox?

Also, today we have an advanced AI that is capable of solving science problems. Should not be difficult to build a GUI that works fast without graphic acceleration, right?

Finally: the modern DDR4 DRAM has approximately 40-50 Gb/s bandwidth. Updating 4K screen at 120 Hz requires 3840 × 2160 × 4 (actually should be 3) × 120 ≈ 4 Gb/s. No problem at all.

I vibed some code using ImGui and it had this problem. I made it so that it only redraws when data changes with a fixed refresh rate and it went away. So it's not a permanent state of affairs.

PDFCraft works fine for me on a 4k screen connected to an older laptop with an integrated Intel graphics card, blazing fast and smooth.

I am using it on a 2017 intel macbook and its faster than anything else on that device

React doesn't re-calc on every change either if you use memoization and such properly.

To use memoization you must use immutable structures (otherwise React is unable to detect changes) which are a pain to use and are slow if not designed properly. Do not believe me, try designing for example an algorithm that accepts a huge immutable sorted list with keys, a large sorted list of bulk deletes/inserts and produces a new sorted list with minimum operations. I made 2 or 3 prototypes and they still are not good and not even working properly.

In my book, a good UI framework simply attaches to a mutable model made of arbitrary objects, detect changes and displays it with minimum number of operations. Doesn't require to use any proxies or immutable data or store data in components. Shouldn't be difficult. Why nobody made it, I do not understand.

This is incorrect. You don’t need to use immutable structures to have stable references which is what matters.

Use context liberally instead of plumbing things through prop’s needlessly and you’re halfway there.

React isn't immediate mode by my understanding.

In my head it's retained mode + the diffing layer, which sounds the same but if you try to write an "immediate-mode" API (say, using hooks) in React you'll find yourself churning a lot.

At least unless you use the magic React compiler that memo-izes everything correctly.

nothing stops you to render gui at 5 fps. most people won't notice

> Why there is no reactive UI that tracks all dependencies and redraws only what needs to be redrawn?

Nowadays the focus seems to be on video game-style interfaces that redraw every frame. The justification for this is typically that computers are so fast they can now come up with the entire interface every frame, so why not take advantage of that and forget all this retained-mode complexity?

They don't realize that this is a classic case of the developer's machine fallacy, where the developer has a machine so vastly more powerful than any of their users' that they produce a terrible experience for said users. This is also why games these days typically require upscaling even on 5090, because developers usually have that or something even more powerful and they think the bleeding edge is pushing even THAT machine to its knees.

Developers should be testing their software on the most entry-level, bottom of the barrel Chromebooks from 2015, running the heaviest and most bloated operating system they can think of. If people still optimized their software for that, then maybe computers would still feel almost as fast as the Apple II from 1977.

https://danluu.com/input-lag/

And obviously all computers have infinite capacity batteries to maintain game-level power consumption.

Or are plugged into a world with infinite quantity of renewable energy.

That's actually a very good point, I haven't seen any care for power consumption from software developers in many many years. The only people who seem to still care about it are hardware developers like Valve and Apple. I admit I never thought about it myself either.

I would figure that doing less work generally requires less power, but some developers are crazy and act like they own the whole CPU, generate tons of heat, stress out the cooling system etc. with multithreaded bullshit that did NOT need to be multithreaded.

Not sure why multi threading is a victim. It really depends.

It does indeed depend.

Some multithreaded workloads will use the full logical processor count to pin every core and that can really suck on low-end systems. I think aside from balancing multithreading overhead, this is one of the reasons why some more advanced software (such as 7-Zip) lets you select the number of threads to use for a workload, even if you already know and accept that it'll be expensive until it's completed.

Lots of multithreading things I come across as a developer have a default of something like 4 threads, or only use a certain fraction of logical cores up to a certain maximum, etc. because it's generally more polite not to always pin every core.

Depending on what you're doing GPU accelerated rendering is more battery friendly than CPU rendering though.

Drawing the entire interface is more expensive than drawing only what changed, though. You don't have to give up the GPU for that.

How long can a phone run on a battery when playing games? A day? Or an hour? Clearly shows how "efficient" GPU is.

I mean, if the game used CPU for rendering, it would last even less long.

Reply on news.ycombinator.com