treeform / windy

Windowing library for Nim using OS native APIs.
MIT License
117 stars 16 forks source link

add win32 WM_SIZING event #96

Closed chancyk closed 2 years ago

chancyk commented 2 years ago

There seems to be another Windows event to get continuous resizing. WM_SIZE alone seems to have a "debounce" behavior, that produces this issue if we redraw every resize:

image

Using only WM_SIZING produces the inverse, where it will redraw occasionally while dragging but not once you stop, leaving the same black border issue.

Combining the two seems to solve the problem, but do you want to provide a similar behavior as Windows where there's a final "resized" event and a separate continuous "resizing" event? I find the Windows method kind of strange personally, at least for drag based resizing, because they're both essentially continuous and it just depends on how quickly you're dragging the window.

chancyk commented 2 years ago

For reference: https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-sizing

chancyk commented 2 years ago

There's something else going on here actually. WM_SIZING and WM_SIZE actually seem to be duplicate events, so it was something about calling the frame draw twice that was fixing my problem and not the handling of missed resize events.

chancyk commented 2 years ago

Some follow up on this. WM_SIZE works okay calling onFrame, but I had to throttle that actual drawing to 14ms because the onResize events fire much faster than the frame rate (1-2ms) which was causing a lot of glitching. There's still a small issue in that the throttling causes the final WM_SIZE event to not draw, and the regular onFrame won't fire while the mouse button is held down, which results in a black border until the mouse button is released. I guess that can be avoided by maintaining some other frame pacing to force draws if the onFrame never fires.