Prefer partial, avoid rerendering if not needed

[ericoporto]

Right now the render checks if anything has changed by hashing the entirety of the command list and only issuing a redraw if needed.

But this means any change with visual impacts - like hovering on a button that has different mouse over and normal colors - will require a full redraw, which is not optimal.

---

I think this can be remade to work in blocks of the command list, so it instead of hashing the entirety and comparing the hash of the previous entirety, it would hash just what gets rendered on each clip rect.

Unfortunately this means traversing the command list twice at different orders and also this will require drawing not in the ascending z-order, which will require proper z-ordered overlays to render things correctly without adding extra steps.

I may need to make a small modified version of the project using the ImGui plug-in to help me monitor and visualize the performance of each function in this module.

[ericoporto]

Very interesting cache implementation here: https://github.com/rxi/lite/blob/master/src/rencache.c

[ericoporto]

Initial work here: https://github.com/ericoporto/ImGi/tree/hashed-zoverlays

unfortunately, I can't figure out a logic that doesn't require z-ordered overlays.

[ericoporto]

Probably the way to go is doing two implementations of rendering, one for the cases where we only have 1 overlay and one for the cases we have a significant range of overlays.

If we only have 1 overlay, we could use the dirty rects technique. Breakup the screen in some rects (4x3?) and workout the hash for each rect by intersecting each one with the draw commands so it's possible. This way we only proceed with the actual drawing if there's a hash change.

Some info for MS dirty rects: https://docs.microsoft.com/en-us/windows/win32/direct3ddxgi/dxgi-1-2-presentation-improvements

[ericoporto]

Thinking about this logic approach to dirty rects will not work well when I add in the option to texture and skin the GUI with sprites. So instead have the best two as best as possible codepaths but try not optimize too much before adding themes with sprites.

Edit: plus if I draw a button sprite, I need to figure out if that sprite changed underneath. :/

[ericoporto]

A write up on cached rendering from rxi: https://rxi.github.io/cached_software_rendering.html

I could use the overlays side by side and then the 20 Overlays give me a 5x4 grid to work with.

[ericoporto]

OK, I think I got a reasonable strategy.

• Have GRID_W x GRID_H, if we can keep it below 20, then we can do use overlays for each
• grid elements can store previous and current hash
• When calculating frame hash, store each command hash separately with the command (maybe do so when drawing already)
• For each grid, intersect all commands, if intersect is different than zero, we use that command hash and store final result on GRID
• For each grid with different hash now than previous, we do drawing and store new hash
• grids with same hash we do nothing, keeping drawing and overlay.

[ericoporto]

I need to redo a bit the hashing so it's done the minimum as possible.

[ericoporto]

Done, Render now uses dirty rects. Need to check real use cases, right now, not sure how better it can be :/