←back to thread

205 points samspenc | 1 comments | | HN request time: 0s | 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 #
krzat ◴[] No.45147379[source]
How does this compare to React-like approach (React, Flutter, SwiftUI)?

It seems like those libraries do what IMGUI do, but more structured.

replies(1): >>45153347 #
1. socalgal2 ◴[] No.45153347[source]
ImGUIs you do whatever you want with your state. You read your state and call UI functions.

React requires knowing about your state because it wants to monitor all of it for changes to try to optimize not doing things if nothing changed. This ends up infecting every part of your code to do so. It's the number 1 frustration I have using React. I haven't used Flutter or SwiftUI so I don't know if they are analogus