←back to thread

205 points samspenc | 1 comments | | HN request time: 0.202s | source
Show context
kg ◴[] No.45146889[source]
This is one scenario where IMGUI approaches have a small win, even if it's by accident - since GUI elements are constructed on demand in immediate mode, invisible/unused elements won't have tooltip setup run, and the tooltip setup code will probably only run for the control that's showing a tooltip.

(Depending on your IMGUI API you might be setting tooltip text in advance as a constant on every visible control, but that's probably a lot fewer than 38000 controls, I'd hope.)

It's interesting that every control previously had its own dedicated tooltip component, instead of having all controls share a single system wide tooltip. I'm curious why they designed it that way.

replies(3): >>45147379 #>>45147966 #>>45147993 #
1. lentil_soup ◴[] No.45147993[source]
No idea why you're getting down voted but that was my thought as well.

With immediate mode you don't have to construct any widgets or objects. You just render them via code every frame which gives you more freedom in how you tackle each UI element. You're not forced into one widget system across the entire application. For example, if you detect your tooltip code is slow you could memcpy all the strings in a block of memory and then have tooltips use an index to that memory, or have them load on demand from disk, or the cloud or space or whatever. The point being you can optimise the UI piecemeal.

Immediate mode has its own challenges but I do find it interesting to at least see how the different approaches would tackle the problem