Box menu drawn in wrong spot when scroll position isn't 0

[rigdern]

Repro steps

I reproed this on Boxer 3.4.19 2024-06-24

1. Download, unzip, and open menu position repro.box.zip.
2. Ensure your window is sized such that there's a vertical scrollbar
3. Vertically scroll down a bit while keeping the top of the list box in view
4. Show the list box's menu by right-clicking on its top-right corner

Unexpected result: The menu is drawn at the wrong Y coordinate. Screenshot:

Potentially related issues

• freeze drawn in wrong spot when scroll position isn't 0 #100

[sgithens]

I took a good serious look at this, and the fixes for it. I might commit a partial fix for 3.4.21, but I might also take this as an opportunity to really fix up how it should work.

This is one of a small handful of things which use this older model of completely taking over the repaint look when the mouse button is down, meaning it just keeps drawing the menu on top of the existing canvas, without the primary repaint routines being called. The only reason this works is that both the front and back buffer contain the last redrawn screen, and this is drawing on top of them, swapping the buffers as you'd expect in GL, but it never actually issues an openGL clear screen.

I'd like to take this opportunity to update this draw style, so that the internal canvas data structure has a bit that keeps track of if the mouse is in a semi persistent state and keep drawing and tracking the menus from that. This will eventually also apply to the hover over icons on box corners (which often get intermittently drawn as well) and other things. This would clean up a great deal finishing us being ready for multiple GL routines and webGL.

[sgithens]

This is fixed in 05ef8f7 , with a first batch of refactoring. There are a few dangling things (that don't impact this fix) to get refactored even a bit more for future repainting in GLFW. Will be included in 3.4.21

[sgithens]

Verified on 3.4.21 and closing.