I believe this is an OS issue. I found, under windows at least, that SDL
applications are literally frozen during resize (and window movement IIRC).
This is why the events appear to be batched, its only when the window is
released that all the events are actually delivered because the main event
loop is allowed to run again. A few years ago I found a hack that could be
used against SDL 1.2 ( http://www.gamedev.net/community/forums/topic.asp?topic_id=428022 ). Its
nasty, but it did the job - on Windows at least. I have no idea whether it
would work in SDL 1.3, or even against newer versions of SDL 1.2.
Might be an avenue worth investigating though…
– Brian
Is there any SDL 1.3 event that comes back to the SDL event queue (the one> that’s accessable via the API) WHILE the border is actually being dragged?
(Note that my posting above points out that resize and possibly expose
events are batched and made available after the window border is released.)
I get the drift, and it looks very promising. I think I can use the event filter to set a flag (any time there’s a resize event) which causes the timer callback to bypass pushing a user event onto the event queue. When the SDL event queue empties out, I’ll “re-enable” the timer. I’ll give it a try and report back. Thanks Brian.
That sure does work nicely with my compiled test case. Problem solved there.
With my APL code (interpreted), the problem is alleviated. But, if I’m very slllloooowwww with a border drag or if I crank up the timer rate, it does crash quite readily. I’ve got one more trick up my sleeve before I give up.
Interesting observation: With APL one core is moderately busy just executing the event loop. If I drag the border to do a resize, a second core comes into the picture. With the compiled C code, I see no change when I drag the border to resize.
Leads me to speculate that my problem with APL is inter-task synchronization. The unpredictability of the problem had me thinking in that direction also.
Set up the timer. When the timer fires, don’t actually invoke the
function in
the timer callback. Instead, you push an user event into the queue with a
code
(SDL_UserEvent.code) that you somehow associate with the function that you
want
to call. This schedules the actual work to be done for later. (The “hard
IRQ.”)
You could do this with a kind of manager module or #define’s. (I’m not
offering
judgment whether these are good methods or not.)
In your event loop, you check for user events. When you find one,
examine its
code and call the function that you earlier identified, optionally with
parameters provided. (The “soft IRQ.”)
I’ve been using this method. But, when I try it with SDL 1.3, although it
works nicely for a constant-sized window, it fails with an access violation
(consistently at location FFFFFFFF) when resizing the window.
I’ve noticed that while you are dragging the window border events are
inhibited until you release the mouse button. Then a flock of resize event
sequences or (resize, expose) sequences (depending on whether you’re making
the window smaller or larger, respectively) become available in the SDL
event queue. I’m firing the timer every three seconds, and it seems like the
failure may be occurring when the timer fires. The timer callback function
isn’t the culprit because it works fine when I’m not resizing.
Because all the resize events are batched, I am unable to work around this
problem.
You might want to check to see how many events are being queued up. The SDL
event queue has a fixed length of 128. Once it is full any additional events
are just dumped until items have been removed from the queue. If for some
odd reason you are letting the queue fill up you can see some very odd bugs.
Bob PendletonOn Wed, Nov 11, 2009 at 1:44 PM, WaltN wrote:
That sure does work nicely with my compiled test case. Problem solved there.
With my APL code (interpreted), the problem is alleviated. But, if I’m very slllloooowwww with a border drag or if I crank up the timer rate, it does crash quite readily. I’ve got one more trick up my sleeve before I give up.
Interesting observation: With APL one core is moderately busy just executing the event loop. If I drag the border to do a resize, a second core comes into the picture. With the compiled C code, I see no change when I drag the border to resize.
Leads me to speculate that my problem with APL is inter-task synchronization. The unpredictability of the problem had me thinking in that direction also.
I apologize for the delay in getting back to this (over a month). I fell, fractured a hip, and it’s taken me this long to get back to APL and SDL.
I implemented an event filter, as suggested earlier, and queued no resize events. Also, I set a flag indicating that sizing is now going on. I ignore any user events associated with timers when that flag is set. That solves the crash problem, but introduces another question: How do I know when a resizing action is complete? Since all resize events are filtered out, there’s no resize event queued upon end-of-resize. What I did was recognize that, if the event queue is empty, resizing can’t be going on. Hence, in my idle-time section, I toggle the resizing flag and call OnResize if the resize flag is set.
I see that Bug 666 deals with this and was fixed as of Rel. 5408. (I’m using 4703.) Does this fix have some mechanism included that senses end of resize?
Windows will post resize events in a tight loop and not return to the
application until the resize is complete. The SDL fix will simply leave the
last resize event in the queue. If you’re grabbing them asynchronously,
you’ll see the events in the queue, but only as fast as you poll.On Thu, Dec 17, 2009 at 11:59 AM, WaltN wrote:
WaltN wrote:
That sure does work nicely with my compiled test case. Problem solved
there.
With my APL code (interpreted), the problem is alleviated. But, if I’m very
slllloooowwww with a border drag or if I crank up the timer rate, it does
crash quite readily. I’ve got one more trick up my sleeve before I give up.
Interesting observation: With APL one core is moderately busy just
executing the event loop. If I drag the border to do a resize, a second core
comes into the picture. With the compiled C code, I see no change when I
drag the border to resize.
Leads me to speculate that my problem with APL is inter-task
synchronization. The unpredictability of the problem had me thinking in that
direction also.
I apologize for the delay in getting back to this (over a month). I fell,
fractured a hip, and it’s taken me this long to get back to APL and SDL.
I implemented an event filter, as suggested earlier, and queued no resize
events. Also, I set a flag indicating that sizing is now going on. I ignore
any user events associated with timers when that flag is set. That solves
the crash problem, but introduces another question: How do I know when a
resizing action is complete? Since all resize events are filtered out,
there’s no resize event queued upon end-of-resize. What I did was recognize
that, if the event queue is empty, resizing can’t be going on. Hence, in my
idle-time section, I toggle the resizing flag and call OnResize if the
resize flag is set.
I see that Bug 666 deals with this and was fixed as of Rel. 5408. (I’m
using 4703.) Does this fix have some mechanism included that senses end of
resize?
I think this is stable for me now that I’m running SVN 5431 (which includes fix for Bug 666) and have implemented disabling posting of user events while resizing. But, this morning, I discovered that a long, drawn out move of a window results in a crash that reminds me of the behavior with resize. And, after disabling posing of user events while moving, the problem went away.
Perhaps move requires a fix similar to that for resize?
Very likely. Thanks for the heads up, I’ll add a similar fix for move as well.
See ya!On Wed, Dec 23, 2009 at 11:10 AM, WaltN wrote:
I think this is stable for me now that I’m running SVN 5431 (which includes
fix for Bug 666) and have implemented disabling posting of user events while
resizing. But, this morning, I discovered that a long, drawn out move of a
window results in a crash that reminds me of the behavior with resize. And,
after disabling posing of user events while moving, the problem went away.
Perhaps move requires a fix similar to that for resize?