We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1710 - README.android: when to start drawing
Summary: README.android: when to start drawing
Status: RESOLVED WONTFIX
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: All Android (All)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-03 05:17 UTC by wboe
Modified: 2013-04-25 08:56 UTC (History)
2 users (show)

See Also:

Attachments
A chapter to be added to README.android (1.79 KB, application/octet-stream)
2013-02-03 05:17 UTC, wboe 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description wboe 2013-02-03 05:17:58 UTC 
Created attachment 1033 [details]
A chapter to be added to README.android

Hi,

I tried an application that worked perfectly on my Andoid tablet on several other Android tablets. It appeared that on most of them the screen remained black. It was not easy to find out what went wrong, because I did not want to buy several different tablets. With some luck and a lot of perseverance I finally found the solution. Maybe it's a good idea to add a chapter to the README.android file so other devs will know what to do. I added my proposal as an attachment.
Comment 1 Philipp Wiesemann 2013-02-03 11:46:49 UTC 
If I understand the chapter correctly then it contains information about a possible race condition in SDL.
I think it would be more useful to fix this fault instead of describing how to avoid it by writing more platform specific source code (e.g. if porting a program using "valid" SDL from another platform).

On the other hand the advice given in the chapter should also be true for other platforms because if the window is not visible drawing makes no sense anyway. So maybe it should not be documented for Android only but be in the general documentation.

I also do not know if it is reliable to wait for SDL_WINDOWEVENT_ENTER or SDL_WINDOWEVENT_RESTORED because maybe they are not send at all. One is send on touches and the other if the surface is "changed" a second time (but maybe this is a reason the render invalidates and the screen gets black anyway).
Comment 2 Gabriel Jacobo 2013-02-03 14:19:57 UTC 
I admit I don't fully understand the additions you posted for the Android README, mostly what I don't understand is the root of the problem you are experiencing, given that the SDL thread is started after Android initializes the GL surface (as you point out correctly), there's no potential race condition there. The surface is created, we get the surfaceChanged event, then we spawn the main app thread.
If there's versions of Android or devices where this doesn't hold true (I haven't seen it happen), we need to solve that problem, can you provide more information on what device, Android version and any OpenGL or SDL errors you may see in the log?

I'd also like to clarify what you mean by the sentence "If your app repaints the whole screen frequently this may stay unnoticed", does this mean drawing only fails on the first (firsts?) frames?
Comment 3 Gabriel Jacobo 2013-02-12 09:39:54 UTC 
I'm setting this to a "waiting" state until we can get more information on the underlying issues Wouter is experiencing and whether or not they fall within SDL's realm.
I don't think the README.android changes can be accepted though.
Comment 4 Philipp Wiesemann 2013-04-01 07:57:41 UTC 
Maybe this bug could be resolved with the new information from SDL's forum/mailing list:

http://forums.libsdl.org/viewtopic.php?t=8889