|Project:||The Open Toolkit library|
Currently there is no way to receive ResizeBegin / ResizeEnd (WM_ENTERSIZEMOVE/WM_EXITSIZEMOVE) events when using GameWindow. I would like to request for this functionality to be added, as it would be useful in numerous situations.
Sometimes computationally expensive operations need to be performed on resize. When a user clicks and drags the window border many Resize events are fired, triggering the expensive computation multiple times. Often, one could defer the expensive operation until ResizeEnd, possibly also providing a computationally cheaper estimate during resize.
One major area of application would be offscreen rendering. It is a common rendering technique nowadays to render to screen sized offscreen buffers for post processing (numerous effects, deferred rendering etc...) and present the result on a fullscreen quad. Having access to the ResizeBegin / ResizeEnd events would enable an elegant solution for resizing the window. Rather than resizing offscreen target each time the Resize event is fired one could wait for the ResizeEnd event and scale the quad in the meantime. Other uses would include redrawing of GUI elements on ResizeEnd and possibly also stopping physics simulation during resize etc...
There are possible workarounds as long as ResizeBegin / ResizeEnd remain inaccessible:
- Be smarter during resize (specifically applies to the offscreen rendering problem): One could decrease/increase the offscreen buffer size "independently" (not completely of course) of the window size and modify the texture coordinates (i.e. as soon as the window area exceeds the current offscreen buffer size double it, that should last for a while...).
- Try to use the mouse state in the Resize event as suggested by Hortus Longus (might be somewhat verbose).
- Install a thread hook to pre-process windows messages (see SetWindowsHookEx and the CallWndProc callback) as suggested by the Fiddler (somewhat inelegant).