undefined

points

[-]

I think the default behavior is to only re-render if the window is active/focused. You can trigger a render at specific points, including in the main loop, which will result in the behavior you mention.

This can be problematic, e.g. some of the sensor interfaces I have, I want to always display correct data, even if not focused. So, I have to decide if I want to have old data shown in the background misleading users, or have a per penalty from constant renders. Or try something else to be clever. (Maybe have it update at a low rate if not focused? I think that's the move...)

by andsoitis3 hours ago|

parent|

[-]

> You can trigger a render at specific points, including in the main loop, which will result in the behavior you mention.

sounds analogous to manual memory management

by WhyNotHugo19 minutes ago|

prev|

[-]

I suspect (and hope) you can block the main loop if no events are received. This avoids re-rendering if the UI is not visible and no interaction has happened.

by user____name8 hours ago|

prev|

[-]

Any quarter decent imgui implementation will idle when there's no input or active animations, and the renderer can generate dirty tiles or rects to unnecessary redrawing -- if it matters, gpus are ridiculously overpowered for drawing a bunch of rectangles. Ui logic is usually firmly in the microseconds realm.

by mort968 hours ago|

parent|

[-]

I agree that this is not a necessary downside to immediate mode GUIs, but we're talking about egui specifically here. AFAIK, egui always redraws at some relatively high rate even when nothing is happening. (I'm having trouble finding documentation about what that rate is though.)

by Boxxed4 hours ago|

parent|

[-]

That's not true, it only re-renders if there's an input event or an animation running. This is very easy to see if you just put a `println!` in your UI logic.

This is also mentioned in the gui docs here https://github.com/emilk/egui#why-immediate-mode:

> egui only repaints when there is interaction (e.g. mouse movement) or an animation, so if your app is idle, no CPU is wasted.

by amelius1 hours ago|

parent|

[-]

Iiuc, a tiny clock in the top right corner of the screen will trigger O(n) work where n is the number of elements on the entire screen. On every change of the clock, e.g. every second. This may be more if there are smooth animations, e.g. 25 times per second if that is the animation frame rate.

by ModernMech4 hours ago|

parent|

prev|

[-]

There are two modes, reactive and continuous. You can switch between them here in the backend tab:

https://www.egui.rs/

Reactive mode is the one you are looking for.

by pixelpoet6 hours ago|

parent|

prev|

[-]

I really wish this were built into imgui as a first-class use case instead of requiring a hodgepodge mix of unofficial hacks.

I recall the author posting an imgui update saying this will be an officially supported mode, but AFAIK it's still not the case. Otherwise I would be building all my applications with imgui going forward.

Re-rendering the screen, even if it's fast, incurs a lot of memory bandwidth to draw everything and swap framebuffers etc. Not something you'd like to happen on mobile, in particular. Just because the waste is "small", doesn't mean it's acceptable.

by halfcat25 minutes ago|

parent|

[-]

Does ImGui work on mobile? I’ve seen it run in web assembly on mobile but typically none of the keyboard inputs work (the mobile keyboard doesn’t pop up, so effectively it’s not usable, at least in that approach).

by freefrog12348 hours ago|

prev|

[-]

By default it re-renders on each event. This isn't often on mobile apps, but moving a mouse across a desktop app triggers multiple vents. There is a function call to request a re-render if you want not to wait for an event.

by mort967 hours ago|

parent|

[-]

So if it's just an idle visible application, does it not render at all because there are no events? Or am I right that there's some idle redrawing going on

by Philpax7 hours ago|

parent|

[-]

With eframe, it does not re-render when idle, no. You need to have another thread that forces it to redraw on your own schedule. It will also redraw when an event occurs (mouse movement, keyboard presses, interacting with the application in general.)

by baq8 hours ago|

prev|

[-]

do you run without a compositor? I get where you're coming from, but 'idle' can mean a lot of different things and redrawing the whole UI at 60hz is not necessarily 'not idle' nowadays.

by mort968 hours ago|

parent|

[-]

I run with a compositor, which is exactly why it's so great for the application to just draw its window once and then the compositor has the window's contents as a texture. The compositor can do whatever it wants with that texture without involvement from the application.