Closed chancyk closed 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.
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.
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:
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.