Author Topic: Window rendering and event processing in Windows (Read 9626 times)

Jesse · « **on:** March 08, 2009, 01:39:55 am »

Currently, if you create a windowed SFML application in Windows (XP - haven't tried Vista), and then drag the window partway off of and then back onto the screen, you get a 'smearing' visual artifact due to the window not updating until the mouse button is released.

Most of the other cross-platform libraries I've tried (SDL, GLFW, etc.) have the same behavior. I've looked into the issue a bit, and unfortunately, it doesn't look like it's entirely trivial to solve, and I imagine fixing this behavior in SFML would probably require significant restructuring of the windowing and events system.

Nevertheless, I thought I'd throw it out there. I've been wrestling with this issue (my project currently uses SDL), and will probably end up re-writing the app to use the native Windows API in order to work around it. In some contexts this 'smearing' probably isn't that big a deal, but for other applications, having the window continue to render correctly as it's moved around the screen can be important.

(This issue may already be in the roadmap, but if so I didn't spot it. Also, if there's a way to work around this problem in SFML, I'd be interested to know about it.)

jdindia · « **Reply #1 on:** March 08, 2009, 02:35:42 am »

I think that's just windows being stupid. There are lots of cases of that. For example your app will basically pause while the user is resizing the window. The default window proc is dumb. =/

Jesse · « **Reply #2 on:** March 08, 2009, 02:57:46 am »

Quote from: "jdindia"

I think that's just windows being stupid. There are lots of cases of that. For example your app will basically pause while the user is resizing the window. The default window proc is dumb. =/

Agreed.

However, it seems there are ways to work around it. A lot of applications (mostly commercial ones) manage to update the rendering area continuously as you move the window around. A few examples:

Windows Media Player
World of Goo
Applications based on Haaf's Game Engine

Other applications 'blank out' the area that's dragged of the screen, but don't have the 'smearing' effect. Marble Blast Gold and Q3-engine-based games are examples of apps that have this behavior.

So I know it can be worked around, and for me at least, having the window continue to render correctly as it's moved around is an important bit of polish for a production-quality app to have. Unfortunately, it doesn't seem that it's entirely straightforward to do. (Solutions I've seen proposed include installing a timer to trigger periodic redraws, or just running everything but the event loop in a separate thread.)

Laurent · « **Reply #3 on:** March 08, 2009, 10:33:33 am »

That's an interesting problem. I'll look into it for SFML 1.5.

Laurent · « **Reply #4 on:** March 09, 2009, 11:43:21 pm »

After looking at the MSDN, I found that this action (dragging or resizing the window) triggers a pair of events : WM_ENTERSIZEMOVE (when you click) and WM_EXITSIZEMOVE (when you release).
Between these two events, Windows runs a modal event loop which means that you and I can't run anything until it's finished. Looks like it's impossible to find a workaround.

I looked at HGE (Haff's Game Engine) source code, and found nothing relevant. So I tried their samples: they have the same problem too.

Now I'm installing the World of Goo demo. If anyone has another example (open source if possible!) please let me know

The only solution I can see right now is to put all the rendering stuff into another thread, so that it doesn't get blocked by the modal event loop.

Megamoscha · « **Reply #5 on:** June 14, 2009, 08:49:33 pm »

It is possible to draw the content of the window when moving or resizing.

All you need is to draw when a WM_SIZE event gets fired.

I used it within a Win32 Application that I once wrote. The problem is that you get a delay for 1 second if you start to drag the window and it is slower when drawing with this event.

It could be that it is also possible to draw when WM_SIZING is fired. But I dunno at the moment.

Laurent · « **Reply #6 on:** June 14, 2009, 09:56:14 pm »

This is impossible, Windows blocks the main thread while the window is being resized/moved.

This would be possible only if SFML was using callbacks for rendering.

Megamoscha · « **Reply #7 on:** June 14, 2009, 10:15:47 pm »

Yeah I find it useless anyway. ;-)

I was just fiddling around if it was possible and I got it working (Window class with a message map. And registered the rendering class for the WM_SIZE event)

VERY USELESS.

Haze · « **Reply #8 on:** December 05, 2011, 12:20:46 pm »

Quote from: "Laurent"

After looking at the MSDN, I found that this action (dragging or resizing the window) triggers a pair of events : WM_ENTERSIZEMOVE (when you click) and WM_EXITSIZEMOVE (when you release).

So, would it be possible to map these events to the SFML event system (something like sf::Event::WindowDragged) ?

Since rendering while dragging window seems impossible, developers could at least pause their application during dragging time and avoid getting an huge frametime when the user finally release the mouse button.

Laurent · « **Reply #9 on:** December 05, 2011, 12:44:49 pm »

This must be tested, but in my opinion the internal blocking loop starts immediately, so the WM_ENTERSIZEMOVE will still be received (by the SFML user) after the whole thing is finished.

Haze · « **Reply #10 on:** December 05, 2011, 01:30:52 pm »

Eh, too bad.
Anyway, some user has found a workaround using threads:
http://www.sfml-dev.org/forum/viewtopic.php?t=5463