3 ms·

I am unsure about where we disagree. What you quoted from me was a set up for my subsequent, unquoted argument. Buttons don't fly around the screen over time.

I am unsure about where we disagree. What you quoted from me was a set up for my subsequent, unquoted argument. Buttons don't fly around the screen over time. If a user clicked on the screen 1.0/144 seconds ago (assuming a 144 htz monitor), the user likely clicked on the button which is about to be redrawn.

mellinoe 9y ago
I guess I don't understand why this would be true: > The imgui framework handles the previous frames events when drawing the current frame. I'm not terribly familiar with the inner workings of these libraries, though, so I could be wrong. Since you pass in the input state for each frame, it's my understanding that they just process the current frame's "events" during that frame. It would be a little weird if you passed some mouse click event into the system and your Button() call returned true the NEXT frame (I think that's what you're suggesting).
- billsix 9y ago
  That is what I'm suggesting. Before I used immediate mode GUIs, I was familiar with using Qt, wx, and gtk. Never did X windows. So I never handled events directly, just indirectly programmed what would happen upon the event occuring. I had been under the likely incorrect assumption that those frameworks, in order to correctly associate say a mouse click to a button, had a mapping of the previous frame's screen-space coordinates of all widgets, and when a click happened, they associated the click with the previously drawn widget. Because that is what was on the screen when the mouse was clicked. Immediate mode GUIs baffled me. How could the drawing of a button, which has not yet been flushed to the monitor, return true or false depending upon whether or not it was clicked? The button is not yet on the monitor!!! After thinking about it for 10 minutes, buttons don't fly all over the screen. Whatever the bounding box for the button for this frame is likely the bounding box it had last frame. So the association is easy, assuming the imgui framework can keep track of object identity across frames. Perhaps, I am just ignorant of how qt, gtk, and wx, actually work.

mellinoe 9y ago

I guess I don't understand why this would be true: > The imgui framework handles the previous frames events when drawing the current frame. I'm not terribly familiar with the inner workings of these libraries, though, so I could be wrong. Since you pass in the input state for each frame, it's my understanding that they just process the current frame's "events" during that frame. It would be a little weird if you passed some mouse click event into the system and your Button() call returned true the NEXT frame (I think that's what you're suggesting).

billsix 9y ago
That is what I'm suggesting. Before I used immediate mode GUIs, I was familiar with using Qt, wx, and gtk. Never did X windows. So I never handled events directly, just indirectly programmed what would happen upon the event occuring. I had been under the likely incorrect assumption that those frameworks, in order to correctly associate say a mouse click to a button, had a mapping of the previous frame's screen-space coordinates of all widgets, and when a click happened, they associated the click with the previously drawn widget. Because that is what was on the screen when the mouse was clicked. Immediate mode GUIs baffled me. How could the drawing of a button, which has not yet been flushed to the monitor, return true or false depending upon whether or not it was clicked? The button is not yet on the monitor!!! After thinking about it for 10 minutes, buttons don't fly all over the screen. Whatever the bounding box for the button for this frame is likely the bounding box it had last frame. So the association is easy, assuming the imgui framework can keep track of object identity across frames. Perhaps, I am just ignorant of how qt, gtk, and wx, actually work.