![]() |
SDL_GL_SwapWindow and Hidden Applications on OS X | ![]() |
Armin Ronacher
Guest
![]() |
![]() |
Hi,
I am currently not delaying by hand in my main loop and just hope for SDL_GL_SwapWindow() to sync with the screen. Which also works perfectly fine for as long as the application is in the foreground. However if the application is minimized or something else hides the window completely the application will instantly consume 100% CPU. I assume that's because that function becomes a noop of some sort. What's the best way to deal with that? Regards, Armin _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||||||||||
|
![]() |
SDL_GL_SwapWindow and Hidden Applications on OS X | ![]() |
Sam Lantinga
![]() |
![]() |
You can handle the minimize event and just wait for the restore event.
On Sat, Mar 5, 2011 at 4:32 AM, Armin Ronacher wrote:
-- -Sam Lantinga, Founder and CEO, Galaxy Gameworks |
||||||||||||
|
![]() |
SDL_GL_SwapWindow and Hidden Applications on OS X | ![]() |
Sam Lantinga
![]() |
![]() |
Here are the window events for reference:
http://wiki.libsdl.org/moin.cgi/SDL_WindowEventID On Sat, Mar 5, 2011 at 10:11 AM, Sam Lantinga wrote:
-- -Sam Lantinga, Founder and CEO, Galaxy Gameworks |
||||||||||||||
|
![]() |
SDL_GL_SwapWindow and Hidden Applications on OS X | ![]() |
Armin Ronacher
Guest
![]() |
![]() |
Hi,
On 3/5/11 7:11 PM, Sam Lantinga wrote:
thing happens. It does not have to be minimized. Regards, Armin _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||||||||||||
|
![]() |
SDL_GL_SwapWindow and Hidden Applications on OS X | ![]() |
Sam Lantinga
![]() |
![]() |
Oh, interesting. Can you enter a bug at http://bugzilla.libsdl.org and include what platform you're seeing this behavior on?
Thanks! On Sat, Mar 5, 2011 at 11:14 AM, Armin Ronacher wrote:
-- -Sam Lantinga, Founder and CEO, Galaxy Gameworks |
||||||||||||||
|
![]() |
SDL_GL_SwapWindow and Hidden Applications on OS X | ![]() |
john skaller
Guest
![]() |
![]() |
On 06/03/2011, at 6:14 AM, Armin Ronacher wrote:
Although you may not need to actually do this if there is a better method, you could try to run a phase locked loop (PLL). Basically, you measure or calculate the approximate expected period of the synchronising signal P, and change your algorithm so you only call SDL_GL_SwapWindow() at time P - E where E is suitably small, eg 10% of P. By keeping the timer running, you will measure E', the time waiting for SDL_GL_SwapWindow() to return, and if E' is close to zero, something is wrong! So (a) you can ensure you don't hog the CPU by using a timer to schedule the Swap call, and (b) you can detect when the signal is abnormal. Abnormal might not be "window minimised or covered up": it might be a resolution change or anything else (dog ate monitor cable ..) This technique is quite general, it can be used to synchronise with any external periodic event. In my case it was used to synchronise with mains Alternating Current to control the intensity of lights. It is also used to lock onto radio signals (Super-heterodyne circuit I think). PLL should be used in professional games = simulations to ensure a constant framerate. To my knowledge it isn't. Games are a bit tricky because load varies suddenly, so PLL needs to be combined with load prediction. If you have a sudden change (a big explosion or whatever) it should be rendered with minimal quality first, the load measured and the quality pushed up until the load is just enough to fit in the frame time. The usual way to handle this problem in simulations is to throw huge amounts of money at the simulator .. hence the small difference between Microsoft Flight Simulator and an passenger aircraft simulator. Just for fun: I recall some years ago seeing one of the first 3D movies made, shown on an IMax screen. This was real footage taken on the International Space Station. At the beginning a satellite is being deployed an there's an accident and the astronaut goes flying off into space, a-la 2001... Yea, its real footage alright .. real footage of a simulated accident. Later the real footage of the actual deployment including docking of the space shuttle is shown. [The point: the simulation was itself 3D and indistinguishable from the real thing .. well it fooled me anyhow :] -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||||||||||||||
|
![]() |
SDL_GL_SwapWindow and Hidden Applications on OS X | ![]() |
Armin Ronacher
Guest
![]() |
![]() |
Hi,
On 3/6/11 11:03 AM, john skaller wrote:
additionally to 200Hz by delaying with SDL_Delay. That works good enough for the time being but it's somewhat of a hack. Regards, Armin _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||||||||||||
|
![]() |
SDL_GL_SwapWindow and Hidden Applications on OS X | ![]() |
john skaller
Guest
![]() |
![]() |
On 07/03/2011, at 1:19 AM, Armin Ronacher wrote:
That depends on whether you consider the frame sync signal to be reliable or not. Your OP suggests that signal isn't reliable. Using a PLL to track its frequency and status IS reliable, though it takes some experimentation to get the tracking parameters right. Note on my Mac the Nehe demos stop dead when in a window and the window loses mouse focus. I have no idea why, but that's another case. Different platforms may behave differently. And as mentioned a PLL can also assist in overload resulting in overshooting your time frame. In turn this allows higher quality graphics rendering to be deployed when there is time and downgraded when there isn't. I guess this applies to mixing sound as well, where timing is probably even more critical than graphics. Ultimately real time systems (such as games) can only work by monitoring (polling/sampling) external events and attempting to synchronise with them, and this also includes noise rejection. Self-synchronising calls (as SDL_GL_SwapWindow() seems to be) and interrupt driven code seems to be the easy way for simple applications but in the long run for more complex applications actually gets in the way, there's more and more tendancy to buffer away these locked operations (eg signals setting a flag, or synchronised calls being de-synchronised by putting them in a thread) and using a single synchronisation source (namely a timer). This is basically what an Operating System does. And at the heart of it, a game is a Real Time operating system ![]() -- john skaller _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
||||||||||||||
|