6 ms·

So egui is great for projects where the application runtime is short lived, or for overlays in longer lived projects. The visual equivalent of scripts, where yo

So egui is great for projects where the application runtime is short lived, or for overlays in longer lived projects. The visual equivalent of scripts, where you know you need a small amount of immediate visual feedback and tweaking parameters for it to be useful to the end user. Flutter answers questions about more robust UI. It's good that you chose the right tool for the job and more people should know that there are options. But fundamentally I'm most motivated by the possibility of a robust UI framework made from first principles to be as low friction as egui but with the accessibility, performance, and visual flexibility of stylable retained mode guis. Raph Levien and the xilem project might be getting us closer.

Aeolun 1y ago
If your UI is fast enough, why not in complex UI’s either? I’d say it gives you good motivation to keep your UI handling code as fast as possible.
- mort96 1y ago
  Doesn't egui always re-render? I like my idle apps to be doing nothing, I don't want them running their render loop in the background
  - baq 1y ago
    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.
    - mort96 1y ago
      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.
  - user____name 1y ago
    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.
    - mort96 1y ago
      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.)
      - Boxxed 1y ago
        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 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.
        amelius 1y ago
        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.
        Aeolun 1y ago
        Sure, but it will consume less CPU than an idle instance of Electron. Or the effort it takes to redraw a React app even once.
      - ModernMech 1y ago
  - freefrog1234 1y ago
    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.
    - mort96 1y ago
      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
      - Philpax 1y ago
        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.)
  - the__alchemist 1y ago
    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...)
    - andsoitis 1y ago
      > 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
      - hoppp 1y ago
        Which is completely fine. There are bugs but unlike with memory management, render bugs are more in your face.
        andsoitis 1y ago
        which is why, I think, it is better to not have to do that manual rendering gymnastics when retained mode does it for you.
        mort96 1y ago
        Let's not pretend that retained mode is somehow easy. Procedurally changing the system's state in response to events gets pretty complex. A philosophy which approximates the II as a function of state is tempting, in a lot of ways. As someone with a fair amount of experience of both retained mode and immediate mode UIs, I can't confidently say that retained mode requires less "mental gymnastics" than immediate mode.
      - mort96 1y ago
  - WhyNotHugo 1y ago
    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.
  - throwawayffffas 1y ago
    You typically set it up so that it does not re-render when it's idle. Or at least not at 60fps. By the way once upon a time, visual studio code I think it was, was using like 20% cpu when idle just because of the blinking cursor, fun.
piker 1y ago
Both approaches have their downsides and, in my view, retained mode and immediate mode tend to converge as the UI complexity increases. So far, no problems with implementing any UI I want in my experience with egui on a somewhat complicated application (Desktop word processor). Immediate mode is a breath of fresh air from React. [Edit: although the standard accessibility criticisms apply to my application; although that's more of an issue with my implementation than an indictment of immediate mode generally.]
- the__alchemist 1y ago
  I'm curious too. I currently have both a plasmid editor, and protein/molecule viewer using EGUI. Both have complex UIs, and I haven't hit roadblocks. I think the protein viewer might be more of a canonical immediate-mode case, because most of the window is a 3D render, but it still has a GUI above it.
  - smj-edison 1y ago
    Kind of off topic, but a protein viewer in Rust sounds really interesting! Is the source code available? I'd love to poke through it (understandable if not though).
    - the__alchemist 1y ago
      Yep - https://github.com/David-OConnor/daedalus/ https://github.com/David-OConnor/daedalus/
- nopelynopington 1y ago
  I'm also thinking of building a word processor so I'd be interested to see what you're working on if you fancy sharing?
  - piker 1y ago
    Sure, it's https://tritium.legal/preview https://tritium.legal/preview
j45 1y ago
Appreciate the thoughts about both Flutter and egui. It's not perfect, but I don't know if there's much on the market that addresses robust UI and single code base as well as Flutter. Very open to other things that are not more complex than Flutter to accomplish the single codebase to multi platform solution it does provide.
dotancohen 1y ago
> egui is great for projects where the application runtime is short lived What is good for a long-lived application, such as an email client? I'm looking for something that fits the same place that Qt fits in the Python world. Accessibility and keyboard shortcuts are of extreme importance.
- merksoftworks 1y ago
  Some of the QT people have forked off and started working on slint[1], iced[2] is the most mature gui in the rust ecosystem right now (in my opinion), but still lacking in some ways, including portability to mobile and component libraries are sort of against the design principle so it's allergic to network effects. Iced is built on some pretty orthodox elm architecture principles by some very talented and devs - but they leave very little room for impurity. [2] https://iced.rs/ https://iced.rs/ [1] https://slint.dev/demos https://slint.dev/demos

Aeolun 1y ago

If your UI is fast enough, why not in complex UI’s either? I’d say it gives you good motivation to keep your UI handling code as fast as possible.

mort96 1y ago
Doesn't egui always re-render? I like my idle apps to be doing nothing, I don't want them running their render loop in the background
- baq 1y ago
  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.
  - mort96 1y ago
    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.
- user____name 1y ago
  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.
  - mort96 1y ago
    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.)
    - Boxxed 1y ago
      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 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.
      - amelius 1y ago
        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.
        Aeolun 1y ago
        Sure, but it will consume less CPU than an idle instance of Electron. Or the effort it takes to redraw a React app even once.
    - ModernMech 1y ago
- freefrog1234 1y ago
  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.
  - mort96 1y ago
    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
    - Philpax 1y ago
      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.)
- the__alchemist 1y ago
  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...)
  - andsoitis 1y ago
    > 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
    - hoppp 1y ago
      Which is completely fine. There are bugs but unlike with memory management, render bugs are more in your face.
      - andsoitis 1y ago
        which is why, I think, it is better to not have to do that manual rendering gymnastics when retained mode does it for you.
        mort96 1y ago
        Let's not pretend that retained mode is somehow easy. Procedurally changing the system's state in response to events gets pretty complex. A philosophy which approximates the II as a function of state is tempting, in a lot of ways. As someone with a fair amount of experience of both retained mode and immediate mode UIs, I can't confidently say that retained mode requires less "mental gymnastics" than immediate mode.
    - mort96 1y ago
- WhyNotHugo 1y ago
  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.
- throwawayffffas 1y ago
  You typically set it up so that it does not re-render when it's idle. Or at least not at 60fps. By the way once upon a time, visual studio code I think it was, was using like 20% cpu when idle just because of the blinking cursor, fun.

piker 1y ago

Both approaches have their downsides and, in my view, retained mode and immediate mode tend to converge as the UI complexity increases. So far, no problems with implementing any UI I want in my experience with egui on a somewhat complicated application (Desktop word processor). Immediate mode is a breath of fresh air from React. [Edit: although the standard accessibility criticisms apply to my application; although that's more of an issue with my implementation than an indictment of immediate mode generally.]

the__alchemist 1y ago
I'm curious too. I currently have both a plasmid editor, and protein/molecule viewer using EGUI. Both have complex UIs, and I haven't hit roadblocks. I think the protein viewer might be more of a canonical immediate-mode case, because most of the window is a 3D render, but it still has a GUI above it.
- smj-edison 1y ago
  Kind of off topic, but a protein viewer in Rust sounds really interesting! Is the source code available? I'd love to poke through it (understandable if not though).
  - the__alchemist 1y ago
    Yep - https://github.com/David-OConnor/daedalus/ https://github.com/David-OConnor/daedalus/
nopelynopington 1y ago
I'm also thinking of building a word processor so I'd be interested to see what you're working on if you fancy sharing?
- piker 1y ago
  Sure, it's https://tritium.legal/preview https://tritium.legal/preview

j45 1y ago

Appreciate the thoughts about both Flutter and egui. It's not perfect, but I don't know if there's much on the market that addresses robust UI and single code base as well as Flutter. Very open to other things that are not more complex than Flutter to accomplish the single codebase to multi platform solution it does provide.

dotancohen 1y ago

> egui is great for projects where the application runtime is short lived What is good for a long-lived application, such as an email client? I'm looking for something that fits the same place that Qt fits in the Python world. Accessibility and keyboard shortcuts are of extreme importance.

merksoftworks 1y ago
Some of the QT people have forked off and started working on slint[1], iced[2] is the most mature gui in the rust ecosystem right now (in my opinion), but still lacking in some ways, including portability to mobile and component libraries are sort of against the design principle so it's allergic to network effects. Iced is built on some pretty orthodox elm architecture principles by some very talented and devs - but they leave very little room for impurity. [2] https://iced.rs/ https://iced.rs/ [1] https://slint.dev/demos https://slint.dev/demos