Hi! Currently SDL thread suspends in SDLSurface.surfaceDestroyed() and resumes in surfaceChanged(). It works great when you switch to another app and come back, but such method doesn’t cover all cases! For example, if you press Power button to lock your screen surfaceDestroyed() won’t be called and your game won’t be paused, but it should, doesn’t it?
So why you chose this way? Why not to use onPause() and onResume()? Or may be stop game when activity loses its focus? What do you think?
In general there could be some cases when surface won’t be destroyed but SDL thread should be stopped.
Hey,
Interestingly, I have just spotted that last week. As a result I have
opened a bug with a suggested patch:
https://bugzilla.libsdl.org/show_bug.cgi?id=1896
Without this, an SDL app can finish your battery life when you don’t
expect it! (Let’s hope it does finish it when you expect it otherwise…)On 06/10/2013 02:55 PM, mastermind wrote:
Hi! Currently SDL thread suspends in SDLSurface.surfaceDestroyed() and
resumes in surfaceChanged(). It works great when you switch to another
app and come back, but such method doesn’t cover all cases! For example,
if you press Power button to lock your screen surfaceDestroyed() won’t
be called and your game won’t be paused, but it should, doesn’t it?
So why you chose this way? Why not to use onPause() and onResume()? Or
may be stop game when activity loses its focus? What do you think?
There is error in your patch. You are trying to check if surface is valid in onPause() but it will be always valid because surfaceDestroyed() called after onPause() in all cases.
NY00123 wrote:
Hey,
Interestingly, I have just spotted that last week. As a result I have
opened a bug with a suggested patch:
https://bugzilla.libsdl.org/show_bug.cgi?id=1896Without this, an SDL app can finish your battery life when you don’t
expect it! (Let’s hope it does finish it when you expect it otherwise…)Hi! Currently SDL thread suspends in SDLSurface.surfaceDestroyed() and
resumes in surfaceChanged(). It works great when you switch to another
app and come back, but such method doesn’t cover all cases! For example,
if you press Power button to lock your screen surfaceDestroyed() won’t
be called and your game won’t be paused, but it should, doesn’t it?
So why you chose this way? Why not to use onPause() and onResume()? Or
may be stop game when activity loses its focus? What do you think?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Code:> On 06/10/2013 02:55 PM, mastermind wrote:
not a bug but will note anyhow:
SDL_DollarGestureEvent: numFingers: Uint32
SDL_MultiGestureEvent: numFingers Uint16;
uint16 isn’t used very often …–
john skaller
@john_skaller
http://felix-lang.org
That may be true where I have tested it. I had read before that certain
things work differently when different Android-powered devices are
involved, though. So the check for the validity of the surface is no
more than a minor safety measure.
Furthermore, there may be a better way to handle that. But the app
should pause, at least!On 06/11/2013 03:39 PM, mastermind wrote:
There is error in your patch. You are trying to check if surface is
valid in onPause() but it will be always valid because
surfaceDestroyed() called after onPause() in all cases.NY00123 wrote:
Hey,Interestingly, I have just spotted that last week. As a result I have
opened a bug with a suggested patch:
https://bugzilla.libsdl.org/show_bug.cgi?id=1896Without this, an SDL app can finish your battery life when you don’t
expect it! (Let’s hope it does finish it when you expect it otherwise…)On 06/10/2013 02:55 PM, mastermind wrote:
Quote:
Hi! Currently SDL thread suspends in SDLSurface.surfaceDestroyed() and
resumes in surfaceChanged(). It works great when you switch to another
app and come back, but such method doesn’t cover all cases! For example,
if you press Power button to lock your screen surfaceDestroyed() won’t
be called and your game won’t be paused, but it should, doesn’t it?
So why you chose this way? Why not to use onPause() and onResume()? Or
may be stop game when activity loses its focus? What do you think?
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Code:
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
NY00123 wrote:
That may be true where I have tested it. I had read before that certain
things work differently when different Android-powered devices are
involved, though. So the check for the validity of the surface is no
more than a minor safety measure.
You right, it’s not error, you just call enableSensor twice 
also surface doesn’t get destroyed after locking screen, but SDL tries to create new surface each time after onResume() which causes warnings in logcat. This part of code should be definetly revised :?
The surface is recreated from a different thread, so I am not sure of a
clean way to handle that in a possibly short time frame that we may have
now.
I think the surface-recreation warnings may go away if the patch from
the following bug report is applied:
https://bugzilla.libsdl.org/show_bug.cgi?id=1889
At the moment, though, that patch (from bug report 1889) always
recreates the GL context. While it is possible to try and use an
existing one with minor modifications to the patch (as already done
without it), maybe a user of SDL 2.0 actually wants to do something that
requires a context recreation at some point (like changing to a
different OpenGL ES API version). Furthermore, it is still the case that
an Android app should be prepared for the possibility that the context
has to be recreated after resume (at least when something like
SDL_WINDOWEVENT_RESTORED is received).On 06/13/2013 03:11 PM, mastermind wrote:
You right, it’s not error, you just call enableSensor twice Smile also
surface doesn’t get destroyed after locking screen, but SDL tries to
create new surface each time after onResume() which causes warnings in
logcat. This part of code should be definetly revised Confused
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org