the Fiddler's picture

[NativeWindow] Avoid modal loop during window resize/movement

Project:The Open Toolkit library
Version:0.9.9-3
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed
Description

This issue only affects the windows implementation: NativeWindow enters a modal loop while the user is resizing or moving the window. During this time, no user code can run (i.e. no UpdateFrame/RenderFrame events).

The typical workaround is to register a timer when NativeWindow receives a WM_ENTERSIZEMOVE message and remove it when it receives a WM_EXITSIZEMOVE message.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#1

Status:open» in progress

The easy part of this issue is now implemented: a timer starts running whenever we enter the modal loop.

The hard part is to find a way to raise the Update-/RenderFrame events when we are stuck inside the ProcessEvents implementation. An event could work, but I don't like the design (the INativeWindow implementation would provide an event that's only used by the GameWindow on win32 - not NativeWindow and not other platforms!)

Any other ideas?

the Fiddler's picture

#2

Found a solution that could potentially be much simpler to implement: simply raise UpdateFrame and RenderFrame events whenever we receive a Resize or Move event.

This seems to solve the problem on Windows - still need to check that it doesn't cause any side effects on other platforms.

Edit: doesn't seem to be enough, unfortunately. No messages are generated when the user clicks the bar but does not move or resize the window. However, we can still generate Move events periodically in this case - should be enough to keep the application running.

Edit 2: and of course, once we do that we encounter a 500ms delay between clicking the window and starting the timer, for no apparent reason. Things are starting to get pretty complicated for what should be a very simple issue - but that's win32 to you.

the Fiddler's picture

#3

Status:in progress» fixed

Partial solution committed to rev 2314. Rendering will still stop if the user opens the context menu or clicks the minimize/maximize buttons, but it is better than nothing.

It seems that the only 100% reliable solution is to render from a different thread. The issue is that this would be much more complex to implement and I do not think it is worth it at this point.

Some more information on the issue: http://www.gamedev.net/community/forums/topic.asp?topic_id=520860

Inertia's picture

#4

Sounds like a good solution to me, most games are fullscreen and will not bother with window move/resize/minimize/maximize at all. For editors (or tools in general) there is usually no need to update the view unless the user explicitly triggers this by either manipulating objects or the camera. It should be rather hard to do both: change the window's properties and manipulate application's data at the same time (i.e. frame).

the Fiddler's picture

#5

Version:0.9.x-dev» 0.9.9-3
Status:fixed» closed

Closing issues fixed in 0.9.9-3.