Wish: Window size/position change event

[Oldes]

Hi Andre,

do you plan to add event for window size/pos changes? I'm volunteering to write it for Win32, if you don't have it already in private.

[floooh]

Yes, I've been planning to add stuff like this "as needed".

Also things like minimized/maximized/restored and 'quit-requested' events.

Please don't bother with a PR though, sokol_app.h is still quite a bit in flux. It'll go in within the next few days I think.

[Oldes]

Ok... I have it running if you would want it. Btw... I have related question... so far when you drag window or resize it, it halts the main thread. It would be better if content inside was not halted. Do you want to change it too? Thanks.

[floooh]

The 'halt-the-main-thread' thing only happens on Windows, I guess because moving/resizing is "modal" there. It would be good to fix this, do you know what the recommend fix for this is (I guess calling the frame callback during a WM_* message?).

[Oldes]

Maybe this helps: https://stackoverflow.com/a/18043461/494472

[Oldes]

I think that the only proper way is to use separate thread. GLFW examples are working the same way.. only the GLFW's threads test (using tinycthread) is not blocking.

[floooh]

Hmm, no IMHO a separate thread is out of question. I'd rather have no updates during moving/resizing. I'll play around with it a bit, I think a lot can be achieved by calling the frame callback from within the WinProc.

[Oldes]

If separate thread is out of question, than there is only option described in:

Windows runs this moving/sizing loop as long as the user is interactively moving/sizing the window. It does this so that it can intercept mouse messages and process them accordingly. When the moving/sizing operation completes (e.g., when the user releases the mouse button or presses the Esc key), control will return to your application code.

It is worth pointing out that you are notified that this mode change has occurred via the WM_ENTERSIZEMOVE message; the corresponding WM_EXITSIZEMOVE message indicates that the modal event-processing loop has exited. That allows you to create a timer that will continue to generate WM_TIMER messages that your application can process. The actual details of how this is implemented are relatively unimportant, but the quick explanation is that DefWindowProc continues to dispatch WM_TIMER messages to your application inside of its own modal event processing loop. Use the SetTimer function to create a timer in response to the WM_ENTERSIZEMOVE message, and the KillTimer function to destroy it in response to the WM_EXITSIZEMOVE message.

As there is small delay before WM_ENTERSIZEMOVE is received, I guess that same method is used in Adobe AIR, where is also noticeable halt before the content is again updating. It is not perfect, but at least it is not halted when you drag a window.

[floooh]

FYI I have started to implement resize, iconified and restored (un-iconified) events. This is basically a subset of what GLFW is doing (and also implemented in the same way). If it makes sense I'll also add a focused/unfocused event later.

I left out the position-changed event, do you know of a scenario where this is required? IMHO size changes is the most important (I also removed the per-frame check for size changes on the platforms where those events are implemented, currently only MacOS and Win32).

[floooh]

Similar sokol-app events have been implemented now, closing this...