Calling video functions from SDL event filter

[Jesse_A]

I’m trying to get an SDL window to re-paint while it’s being dragged (this is
in Windows, using SDL 1.2.13 and OpenGL).

I’ve seen a workaround proposed where an event filter is installed, and then
a render function is called from the event filter in response to
SDL_VIDEOEXPOSE events. I gather this is generally considered inadvisable
for thread safety reasons.

However, here’s what I’m wondering. My understanding (which may be
incorrect) is that the Windows ‘message proc’ function is always called from
the thread that created the window. Also, from looking at the SDL code it
appears that SDL_VIDEOEXPOSE events are only dispatched to the event filter
from the message proc.

It seems it would follow then that in Windows, if you receive an
SDL_VIDEOEXPOSE event in your event filter, you’re guaranteed to be in the
main thread, in which case it would be safe to call SDL video functions.

Am I overlooking anything here? Or is this workaround indeed safe as long as
it’s confined to Windows operating systems?–
View this message in context: http://www.nabble.com/Calling-video-functions-from-SDL-event-filter-tp22494437p22494437.html
Sent from the SDL mailing list archive at Nabble.com.

[Donny_Viszneki]

Is it established why it is not painting to begin with?On Fri, Mar 13, 2009 at 7:25 AM, Jesse A. wrote:

I’m trying to get an SDL window to re-paint while it’s being dragged (this is
in Windows, using SDL 1.2.13 and OpenGL).

–
http://codebad.com/

[Jesse_A]

Is it established why it is not painting to begin with?

In Windows, the main thread is blocked while the window is being dragged,
which can cause rendering artifacts when the window is moved around. To see
this effect, run an application that uses SDL and OpenGL, and then drag the
window partway off of and then back onto the screen. In most (maybe all)
cases, you’ll see a ‘smearing’ effect that persists until the mouse button
is released.

While the window is being moved, Windows dispatches various messages to the
message callback, one of which is WM_PAINT. As I understand it, Windows apps
typically redraw in response to this message to avoid artifacts like the one
described above.

When using SDL, however, the WM_PAINT messages aren’t passed on to the user
(for portability reasons, I assume), so there’s no opportunity to re-paint
in response to window events such as dragging or resizing. The ‘event
filter’ workaround seems to address this problem, so I’m trying to determine
if it’s safe to use this workaround as long it’s only used in the Windows
environment.–
View this message in context: http://www.nabble.com/Calling-video-functions-from-SDL-event-filter-tp22494437p22495479.html
Sent from the SDL mailing list archive at Nabble.com.

[Donny_Viszneki]

Is it established why it is not painting to begin with?

In Windows, the main thread is blocked while the window is being dragged,
which can cause rendering artifacts when the window is moved around. To see
this effect, run an application that uses SDL and OpenGL, and then drag the
window partway off of and then back onto the screen. In most (maybe all)
cases, you’ll see a ‘smearing’ effect that persists until the mouse button
is released.

Ok, but why is this happening?

While the window is being moved, Windows dispatches various messages to the
message callback, one of which is WM_PAINT. As I understand it, Windows apps
typically redraw in response to this message to avoid artifacts like the one
described above.

I suspect the window compositing in Vista largely eliminates this
issue since your window does not get “damaged” anymore (or probably
less often, anyhow.)

When using SDL, however, the WM_PAINT messages aren’t passed on to the user
(for portability reasons, I assume), so there’s no opportunity to re-paint
in response to window events such as dragging or resizing.

This sounds different from your above explanation: that the main
thread is blocked while the window is being dragged.

Anyhow, how would this make it more portable?On Fri, Mar 13, 2009 at 8:32 AM, Jesse A. wrote:

–
http://codebad.com/

[Jesse_A]

Ok, but why is this happening?
It’s just a result of how SDL interoperates with Windows.

I suspect the window compositing in Vista largely eliminates this

issue since your window does not get “damaged” anymore (or probably
less often, anyhow.)
I haven’t had a chance to test the app on Vista. For the time being at
least, I’m just trying to get this working in XP.

This sounds different from your above explanation: that the main

thread is blocked while the window is being dragged.
The main thread is blocked; however, certain events (notably WM_PAINT)
continue to be dispatched to the message handling procedure. When using SDL
though, the only way to receive these events, as far as I can tell at least,
is through the event filter.

Again, this is just as I understand it. I’m not an expert on the Windows
API, which is one of the reasons I’m asking about this here

Anyhow, how would this make it more portable?
The goal is not portability, but rather to prevent the aforementioned
rendering artifacts from occurring in the Windows version of the
application. In other words, this would be a platform-specific workaround
(Windows only).

Here are a couple of other threads on the same topic that might make things
more clear:

http://www.nabble.com/OS-X-%2B-SDL_SetEventFilter-%3D-Bus-Error-td14613214.html#a14624296
http://www.nabble.com/OS-X-%2B-SDL_SetEventFilter-%3D-Bus-Error-td14613214.html#a14624296

SDL window resize glitch

SDL window resize glitch

View this message in context: http://www.nabble.com/Calling-video-functions-from-SDL-event-filter-tp22494437p22496788.html
Sent from the SDL mailing list archive at Nabble.com.

[Donny_Viszneki]

I’m trying to get an SDL window to re-paint while it’s being dragged (this is
in Windows, using SDL 1.2.13 and OpenGL).

http://www.gamedev.net/community/forums/topic.asp?topic_id=428022&forum_id=61&gforum_id=0

OH you’re talking about windows resizing? I was sure you were
talking about moving the window! I suspect this behavior was
deliberately introduced into SDL to prevent it from have to reallocate
framebuffer surfaces a hundred times during a window resize. Although
the WM_PAINT signal may arrive, Windows did not in the past require a
framebuffer to be associated with the contents of your window, only
the contents of the display. Also as I said, Vista now manages a
framebuffer for your window in its compositing layer (but again I’m
not sure you can rely on that framebuffer always being around.)

This sounds different from your above explanation: that the main
thread is blocked while the window is being dragged.
The main thread is blocked; however, certain events (notably WM_PAINT)
continue to be dispatched to the message handling procedure. When using SDL
though, the only way to receive these events, as far as I can tell at least,
is through the event filter.

Again, this is just as I understand it. I’m not an expert on the Windows
API, which is one of the reasons I’m asking about this here

Out of curiosity, what API does the blocking?

Anyhow, how would this make it more portable?
The goal is not portability, but rather to prevent the aforementioned
rendering artifacts from occurring in the Windows version of the
application. In other words, this would be a platform-specific workaround
(Windows only).

I tried quoting this in my last email for clarity, but I’ll quote it again:On Fri, Mar 13, 2009 at 7:25 AM, Jesse A. wrote:
On Fri, Mar 13, 2009 at 9:50 AM, Jesse A. wrote:

On Fri, Mar 13, 2009 at 8:33 AM, Jesse A. wrote:

When using SDL, however, the WM_PAINT messages aren’t passed on to the user
(for portability reasons, I assume)

How would this make it more portable?

–
http://codebad.com/

[Jesse_A]

OH you’re talking about windows resizing? I was sure you were

talking about moving the window!
Actually I was talking about moving rather than resizing, but the problem is
essentially the same in either case.

Out of curiosity, what API does the blocking?
The Windows API.

When using SDL, however, the WM_PAINT messages aren’t passed on to the
user (for portability reasons, I assume)
How would this make it more portable?
Ah, I see what you’re asking. I don’t have an answer - it’s just a guess on
my part. My supposition is that this is handled differently enough on the
various systems that SDL supports that it would be difficult to expose the
functionality in a consistent, thread-safe way. But again, I’m just
guessing.

In any case, I may have made the question more complicated than necessary,
so let me try rephrasing it:

When running a program that uses SDL and OpenGL in Windows XP, if you drag
the window off of the screen, and then back onto the screen, you will see a
’smearing’ visual artifact that persists until the mouse button is released.
My question is, is there any way to work around this, so that the client
area of the window can continue to update even while the window is being
moved?–
View this message in context: http://www.nabble.com/Calling-video-functions-from-SDL-event-filter-tp22494437p22507462.html
Sent from the SDL mailing list archive at Nabble.com.

[Donny_Viszneki]

Is this not the case when using a different OpenGL context manager (like GLUT?)On Fri, Mar 13, 2009 at 8:14 PM, Jesse A. wrote:

When running a program that uses SDL and OpenGL in Windows XP, if you drag
the window off of the screen, and then back onto the screen, you will see a
’smearing’ visual artifact that persists until the mouse button is released.
My question is, is there any way to work around this, so that the client
area of the window can continue to update even while the window is being
moved?

–
http://codebad.com/

[Jesse_A]

Is this not the case when using a different OpenGL context manager (like
GLUT?)
All the OpenGL-based applications and frameworks that I’ve tried in Windows
XP exhibit visual artifacts (either ‘smearing’ or erasing) when the window
is dragged off and on the screen. For the most part, apps that use Direct3D
and the native Windows API don’t seem to have this problem.

Basically, I’m trying to get the window dragging behavior of a 'native’
Windows app (i.e. no smearing or erasing), except with SDL and OpenGL. I’ve
implemented the ‘event filter’ workaround I described earlier, and it seems
to work fine, but this brings me back to my original question: Is this
workaround safe for production code?–
View this message in context: http://www.nabble.com/Calling-video-functions-from-SDL-event-filter-tp22494437p22512218.html
Sent from the SDL mailing list archive at Nabble.com.

[Donny_Viszneki]

Is this not the case when using a different OpenGL context manager (like
GLUT?)
All the OpenGL-based applications and frameworks that I’ve tried in Windows
XP exhibit visual artifacts (either ‘smearing’ or erasing) when the window
is dragged off and on the screen. For the most part, apps that use Direct3D
and the native Windows API don’t seem to have this problem.

Could you list the GL context managers that you’ve tried then?

Basically, I’m trying to get the window dragging behavior of a 'native’
Windows app (i.e. no smearing or erasing), except with SDL and OpenGL. I’ve
implemented the ‘event filter’ workaround I described earlier, and it seems
to work fine, but this brings me back to my original question: Is this
workaround safe for production code?

This doesn’t seem to have anything to do with SDL, so even SDL experts
might not know the answer to your question (doesn’t seem like anyone
else has chimed in yet.) Perhaps asking an OpenGL group? If your
technique using the SDL API could be ported to a GLUT example, that
would probably go a good way toward illustrating what is actually
going on without SDL adding extra complexity to the situation.On Sat, Mar 14, 2009 at 8:36 AM, Jesse A. wrote:

–
http://codebad.com/

[necron]

Hiyya, To craft a solution I need to ask what your app does? What draggin around of a window do you want to drag past the os view?---------------------

---- “Jesse A.” wrote:

=============

OH you’re talking about windows resizing? I was sure you were

talking about moving the window!
Actually I was talking about moving rather than resizing, but the problem is
essentially the same in either case.

Out of curiosity, what API does the blocking?
The Windows API.

When using SDL, however, the WM_PAINT messages aren’t passed on to the
user (for portability reasons, I assume)
How would this make it more portable?
Ah, I see what you’re asking. I don’t have an answer - it’s just a guess on
my part. My supposition is that this is handled differently enough on the
various systems that SDL supports that it would be difficult to expose the
functionality in a consistent, thread-safe way. But again, I’m just
guessing.

In any case, I may have made the question more complicated than necessary,
so let me try rephrasing it:

When running a program that uses SDL and OpenGL in Windows XP, if you drag
the window off of the screen, and then back onto the screen, you will see a
’smearing’ visual artifact that persists until the mouse button is released.
My question is, is there any way to work around this, so that the client
area of the window can continue to update even while the window is being
moved?

View this message in context: http://www.nabble.com/Calling-video-functions-from-SDL-event-filter-tp22494437p22507462.html
Sent from the SDL mailing list archive at Nabble.com.

---

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Jesse_A]

First of all, thanks for the replies so far - I appreciate it.

Donny Viszneki wrote:

Could you list the GL context managers that you’ve tried then?
I’ve tried GLUT, GLFW, and SFML, and they all appear to exhibit the same
behavior.

This doesn’t seem to have anything to do with SDL, so even SDL experts

might not know the answer to your question (doesn’t seem like anyone
else has chimed in yet.)
The problem isn’t exclusive to SDL (other similar cross-platform libraries
have the same problem), but it is related to SDL, or at least it seems to
be. I say this because when using the native Windows API, it’s easy to
refresh the client area of the window as needed while it’s being moved or
resized, whereas with SDL there doesn’t seem to be any standard way of doing
this.

Perhaps asking an OpenGL group?
Yeah, I’ve been looking elsewhere for solutions as well. However, there are
at least some aspects of the problem that are specific to SDL - in
particular, I was hoping some of the SDL experts here might be able to
comment on the safety (or lack thereof) of the ‘event filter’ workaround.

If your technique using the SDL API could be ported to a GLUT example, that
would probably go a good way toward illustrating what is actually going on
without SDL adding extra complexity to the situation.
I’ve looked for equivalent workarounds in the other APIs I mentioned, but
haven’t found anything.

necronology wrote:

Hiyya, To craft a solution I need to ask what your app does? What draggin
around of a window do you want to drag past the os view?
I may be misunderstanding your question, but here’s a quick summary of the
problem. When running an app that uses SDL and OpenGL in windowed mode in
Windows XP, if you drag the window partway off of and then back onto the
screen, you get a ‘smearing’ visual artifact that persists as long as the
window is being moved. When using the Windows API directly, this typically
isn’t a problem - you simply refresh the client area in response to WM_PAINT
messages.

In short, I’m trying to replicate the ‘native’ Windows window dragging
behavior, only using SDL rather than the Windows API, and I’m wondering if
there’s any safe and reliable way to do this.–
View this message in context: http://www.nabble.com/Calling-video-functions-from-SDL-event-filter-tp22494437p22528844.html
Sent from the SDL mailing list archive at Nabble.com.

[slouken]

Yeah, I’ve been looking elsewhere for solutions as well. However, there are
at least some aspects of the problem that are specific to SDL - in
particular, I was hoping some of the SDL experts here might be able to
comment on the safety (or lack thereof) of the ‘event filter’ workaround.

The event filter workaround is fine.

See ya,
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

[Jesse_A]

The event filter workaround is fine.
That’s great - thank you! :)–
View this message in context: http://www.nabble.com/Calling-video-functions-from-SDL-event-filter-tp22494437p22534189.html
Sent from the SDL mailing list archive at Nabble.com.

[Donny_Viszneki]

Donny Viszneki wrote:

Could you list the GL context managers that you’ve tried then?
I’ve tried GLUT, GLFW, and SFML, and they all appear to exhibit the same
behavior.

I guess it doesn’t bother Microsoft since they would rather have
people using Direct3D anyhow.

This doesn’t seem to have anything to do with SDL, so even SDL experts

might not know the answer to your question (doesn’t seem like anyone
else has chimed in yet.)
The problem isn’t exclusive to SDL (other similar cross-platform libraries
have the same problem), but it is related to SDL, or at least it seems to
be. I say this because when using the native Windows API, it’s easy to
refresh the client area of the window as needed while it’s being moved or
resized, whereas with SDL there doesn’t seem to be any standard way of doing
this.

I would think then that it would be preferable to incorporate this
into the OpenGL context managers. Does MSDN have anything to say about
this behavior?On Sun, Mar 15, 2009 at 6:11 PM, Jesse A. wrote:

–
http://codebad.com/

[slouken]

The event filter workaround is fine.
That’s great - thank you!

You’re welcome!

See ya,
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC