4 ms·

Citation needed? I have a not too complex but definitely non-trivial editor I made for a little toy game engine and the Dear ImGUI code and related UI logic run

Citation needed? I have a not too complex but definitely non-trivial editor I made for a little toy game engine and the Dear ImGUI code and related UI logic runs in under 1/10th of a millisecond per frame. My past Qt applications performed worse than that. My single page web applications often perform worse than that But like the other reply says, bad is relative.

andrewmcwatters 5y ago
Immediate mode GUIs are not designed for production. As soon as you want to do compositing, you can’t, because compositing is done with retained structures. Immediate mode GUIs already lie to you by retaining some data then flushing it later.
- formerly_proven 5y ago
  It's not a real immediate mode GUI unless it starts drawing pixels instantly? That's not even how real immediate mode graphics APIs worked.
  - andrewmcwatters 5y ago
    I don't know what your qualm is. I just said that.
    - formerly_proven 5y ago
      Well why do you think it's important (important enough to call immediate mode a lie, even)? Immediate vs. deferred is in my view entirely about the API design, it does not really matter whether an immediate-mode GUI framework is appending to a drawlist when you call into a widget's code or is writing some pixels into some buffer; the point is that it does not have retained state about individual widgets (ImGUI doesn't, don't know about egui). As you say, compositing on a widget level is much, much harder, but even traditional retained frameworks generally only support compositing on a top-level window basis (e.g. partially translucent windows, translucent menus or drop-downs) because as we are seeing (and you point out in another post), compositing between essentially arbitrary stuff is heinously complex to implement, let alone implement with decent performance. I'd be interested to hear what use cases you have in mind for intrawindow compositing.
      - andrewmcwatters 5y ago
        Yeah, I mean, I get what you're saying about the API design. That's probably more important to people because it's fun or novel, but it basically does have retained state about individual widgets. Not literally every individual widget, but it needs to store something, or it wouldn't know what you hovered over, or were dragging and dropping, so it does this with IDs. That's state, and it's retained. That is, it's not flushed after every frame. There's a global state used to track this, but it's just hidden from you. The IDs are probably generated based on call order, since the design requires you to "check" by drawing. Like you said though, even immediate mode rendering in reality worked a bit differently than people really understood. Today we're not actually performing a DMA transfer with every single call. You're generally right about how compositors do effects layering, since you have to continually reference existing texture data to composite layers without limits, though as far as I know, web browsers do this a bit differently, and I'm not sure what the limits are with the major implementations, or if they exist.
jcelerier 5y ago
> Dear ImGUI code and related UI logic runs in under 1/10th of a millisecond per frame. My past Qt applications performed worse than that. are you using freetype font rendering with dear imgui ? because otherwise it's not a fair comparison - just getting a "proper" font rendering (and not ImGUI's default, "okay-for-an-internal-app" font rendering) is a super large computational cost ; last time I had to profile that for my Qt app, just proper font rendering if you have a few thousand characters shown will easily be more than 1/10th of millisecond without counting anything else on a decent computer.

andrewmcwatters 5y ago

Immediate mode GUIs are not designed for production. As soon as you want to do compositing, you can’t, because compositing is done with retained structures. Immediate mode GUIs already lie to you by retaining some data then flushing it later.

formerly_proven 5y ago
It's not a real immediate mode GUI unless it starts drawing pixels instantly? That's not even how real immediate mode graphics APIs worked.
- andrewmcwatters 5y ago
  I don't know what your qualm is. I just said that.
  - formerly_proven 5y ago
    Well why do you think it's important (important enough to call immediate mode a lie, even)? Immediate vs. deferred is in my view entirely about the API design, it does not really matter whether an immediate-mode GUI framework is appending to a drawlist when you call into a widget's code or is writing some pixels into some buffer; the point is that it does not have retained state about individual widgets (ImGUI doesn't, don't know about egui). As you say, compositing on a widget level is much, much harder, but even traditional retained frameworks generally only support compositing on a top-level window basis (e.g. partially translucent windows, translucent menus or drop-downs) because as we are seeing (and you point out in another post), compositing between essentially arbitrary stuff is heinously complex to implement, let alone implement with decent performance. I'd be interested to hear what use cases you have in mind for intrawindow compositing.
    - andrewmcwatters 5y ago
      Yeah, I mean, I get what you're saying about the API design. That's probably more important to people because it's fun or novel, but it basically does have retained state about individual widgets. Not literally every individual widget, but it needs to store something, or it wouldn't know what you hovered over, or were dragging and dropping, so it does this with IDs. That's state, and it's retained. That is, it's not flushed after every frame. There's a global state used to track this, but it's just hidden from you. The IDs are probably generated based on call order, since the design requires you to "check" by drawing. Like you said though, even immediate mode rendering in reality worked a bit differently than people really understood. Today we're not actually performing a DMA transfer with every single call. You're generally right about how compositors do effects layering, since you have to continually reference existing texture data to composite layers without limits, though as far as I know, web browsers do this a bit differently, and I'm not sure what the limits are with the major implementations, or if they exist.

jcelerier 5y ago

> Dear ImGUI code and related UI logic runs in under 1/10th of a millisecond per frame. My past Qt applications performed worse than that. are you using freetype font rendering with dear imgui ? because otherwise it's not a fair comparison - just getting a "proper" font rendering (and not ImGUI's default, "okay-for-an-internal-app" font rendering) is a super large computational cost ; last time I had to profile that for my Qt app, just proper font rendering if you have a few thousand characters shown will easily be more than 1/10th of millisecond without counting anything else on a decent computer.