Deferred rendering

[VisenDev]

It might be worthwhile to discuss implementing a deferred rendering strategy, rather that using immediate mode rendering. From my understanding, this is the strategy that Dear ImGui uses.

Possible advantages

• Less Draw Calls, it should theoretically be possible to render the entire ui interface with very few draw calls - which should improve performance.
• Could help simplify widgets that need to be rendered above or below other widgets, such as dialogs. Currently, we store dialog data using dataSet and then actually call the dialog at the end of the frame. Using deferred rendering, we could call the dialog widget directly and then store the resulting vertex data for deferred rendering like every other widget. Because all vertex data is stored like this, it is easy to change the order in which things are rendered.

I'm not sure whether or not this would be right for dvui, but I was thinking about it so I wanted to discuss it.

[david-vanderson]

I'm open to it if there's some data that shows performance gains that outweigh the added complexity.

Note that we already do deferred rendering for all subwindows (like dialogs and menus).

Dialogs can happen both ways:

• calling dvui.floatingWindow() and adding stuff to it in which case the code is run immediately but the rendering is deferred
• using dvui.dialog() or dvui.dialogAdd() which runs the dialog code at the end of the frame - this is not for deferred rendering but to support "fire and forget" dialogs (like an error message that is generated deep in some stack of functions and you don't expect to get to that spot in the code every frame)