3 ms·

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.

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.