You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: HG 2.1 Reported for operating system, platform: Android (All), ARM
Comments on the original bug report:
On 2013-11-17 21:53:40 +0000, Sylvain wrote:
I open the ticket to trace the issue as reported by Daniel K. with its XperiaE.
SDL application are not working in Landscape : only black screen appear, while the game is working underneath.
(If we turn the screen off/on, we start to see the App, but not rotated correctly).
It appears after this commit : https://hg.libsdl.org/SDL/rev/ac4ce59c40e7
I put debugging information and see no blattant error : it was the same output as a working device.
No SDL_Error Log.
I put also additionnal information.
The only difference I see is the presence of "onWindowFocusChanged()" and "handleResume()" which occur earlier.
but it does not trigger the nativeResume.
On 2013-11-18 00:37:09 +0000, Gabriel Jacobo wrote:
Sorry if I already asked you this, but...does testgles or testrendercopyex work as expected on this device?
On 2013-11-18 00:50:30 +0000, Daniel Knobe wrote:
No, both tests have the exactily the same behavior as the apps Sylvain and I developed.
The blackscreen occurs when I switch in landscape mode by adding a line to the manifest file / adding a line in the java file. In portrait everything works as expected.
Daniel, does it look the same as what you see in XperiaE when it came back after off/on ? (see description of cards collumns, bottom card, background).
On 2013-11-18 09:05:37 +0000, Daniel Knobe wrote:
Created attachment 1451
Starting the app
On 2013-11-18 09:07:21 +0000, Daniel Knobe wrote:
Created attachment 1452
Starting the app, pressing home (running in background) and get into again by starting the app
On 2013-11-18 09:08:25 +0000, Daniel Knobe wrote:
Created attachment 1453
Starting the app, pressing power twice (running in background), slide to unlock to go into app again
On 2013-11-18 09:10:17 +0000, Daniel Knobe wrote:
It's a little bit different. Like we thought it's not a determinate problem.
On the Xperia E I get allways a blackscreen on start (see screenshot: "Starting the app").
I added screenshots, so that it's possible to make a comparison to the apple pics.
On 2013-11-18 09:16:36 +0000, Sylvain wrote:
Yes I agree this looks different.
what I see :
pressing home (Background-Foreground) solves the issue !
Pressing the off/on seems to only make the rendering appears:
I believe the renderer is created with wrong size.
but the pipeline is correctly doing the 90deg rotation !
On 2013-11-18 09:18:35 +0000, Sylvain wrote:
hum I am wrong with my last comment, please ignore it.
On 2013-11-18 09:21:01 +0000, Sylvain wrote:
Ok. could you do the same screenshot with the Spider game ?
this seems stupid but the background is blit in a different way that it reflects the internals of SDL.
On 2013-11-18 09:26:58 +0000, Daniel Knobe wrote:
Absolutly the same behavior in spider.
My games has this behavior, too.
I don't add the screens here (because they contain no new informations).
On 2013-11-18 09:50:43 +0000, Sylvain wrote:
So:
what I see :
pressing home (Background-Foreground) solves the issue !
Pressing the off/on seems to only make the rendering appears:
I believe the renderer is created with correct size.
I draw to size with w=480 h=320. and it fits into the renderer window.
and the backgroung (on spider) fits also. (I use rect dst == NULL).
it take the full size inside the rendered.
the pipeline is correctly doing the 90deg rotation !
but it is also scaling the image which is wrong!
On 2013-11-18 11:56:13 +0000, Gabriel Jacobo wrote:
If the problem exists in testgles, it's fairly safe to assume the problem does not lie in the Renderer code. Can you try a bulk approach to debugging by creating a debug version with SDL_Log statements across the SDL_egl.c and all the JAVA side functions? Maybe that will shed some light as to what's going on without access to the device.
Another question, are you changing the min or target SDK level? Do you see other apps having the same problem?
for the behavier on a working phone, and the one of Daniel.
I screw-up the log of renderer.viewport{x/y/w/h} h is always y for both log
Maybe I miss some java function ?
I put logs wherever I could ...
trace the sendWindowEvent stuff
So far, the diff says :
difference in depth_size and in ES_BIT
onWindowFocusChanged is sent earlier
In my app.. for historical raison, dont know if it have any effect.
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0);
SDL_GL_SetAttribute(SDL_GL_RETAINED_BACKING, 0);
I will remove that in the next log I guess.
And the manifest xml:
On 2013-11-18 20:48:42 +0000, Sylvain wrote:
Created attachment 1454
logcat good 1
On 2013-11-18 20:48:58 +0000, Sylvain wrote:
Created attachment 1455
logcat bad 1
On 2013-11-19 08:27:17 +0000, Sylvain wrote:
I mess-up the logcat. wait again for new logcat please.
On 2013-11-19 11:50:44 +0000, Gabriel Jacobo wrote:
Thanks for this idea, but this doesn't help.
Changing the glViewport on HTC does change the output like it should. On the Xperia E the blackscreen stays black.
On 2013-11-19 14:05:41 +0000, Gabriel Jacobo wrote:
It's unlikely that it is related to what you are seeing, but we are just poking in the dark anyway, so you may as well give it a try.
On 2013-11-19 19:55:37 +0000, Sylvain wrote:
Created attachment 1457
logcat good 2
On 2013-11-19 19:56:36 +0000, Sylvain wrote:
Created attachment 1458
logcat bad 2
On 2013-11-19 20:07:10 +0000, Sylvain wrote:
Good catch about the eglChoose mecanism ! but it doesnt solve the issue !
Also, remember going to background and then foreground is solving the problem,
so the configuration remains the same ?
Here the logcat of a full scenario.
we just do :
start
wait (the eglSwapBuffers)
go to Background
go to Foreground
wait (the eglSwapBuffers)
"Logcat good 2 and background foregound" is with my device
and "bad" is with the XperiaE of Daniel.
There almost no difference
But we can notice during the resuming, the behavior is a little bit different :
"android_egl_context_restore" appears between "there1" and "there2".
so the function with the logging :
324 /* Resume /
325 void Java_org_libsdl_app_SDLActivity_nativeResume(
326 JNIEnv env, jclass cls)
327 {
328 __android_log_print(ANDROID_LOG_VERBOSE, "SDL", "nativeResume()");
329 SDL_Log("MyDebug : %s Android_Window=%p", func, Android_Window);
330
331 SDL_Log("MyDebug : %s WILL ENTER FOREGROUND", func);
332 SDL_SendAppEvent(SDL_APP_WILLENTERFOREGROUND);
333 SDL_Log("MyDebug : %s WILL DID FOREGROUND", func);
334 SDL_SendAppEvent(SDL_APP_DIDENTERFOREGROUND);
335
336
337 if (Android_Window) {
338 /* Signal the resume semaphore so the event loop knows to resume and restore the GL Context
339 * We can't restore the GL Context here because it needs to be done on the SDL main thread
340 * and this function will be called from the Java thread instead.
341 */
342 SDL_Log("MyDebug : %s there1", func);
343 if (!SDL_SemValue(Android_ResumeSem)) SDL_SemPost(Android_ResumeSem);
344 SDL_Log("MyDebug : %s there2", func);
345 SDL_Log("MyDebug : %s FOCUS_GAINED", func);
346 SDL_SendWindowEvent(Android_Window, SDL_WINDOWEVENT_FOCUS_GAINED, 0, 0);
347 SDL_Log("MyDebug : %s RESTORED", func);
348 SDL_SendWindowEvent(Android_Window, SDL_WINDOWEVENT_RESTORED, 0, 0);
349 }
350 }
hope this helps
On 2013-11-19 20:12:31 +0000, Gabriel Jacobo wrote:
Given there's two threads at work here, it may be more helpful to run:
adb logcat -v threadtime
So it's easier to identify which lines come from which thread (and will probably help identify if there's some hidden timing problem)
On 2013-11-19 20:56:56 +0000, Sylvain wrote:
Created attachment 1459
logcat good 3
On 2013-11-19 20:57:23 +0000, Sylvain wrote:
Created attachment 1460
logcat bad 3
On 2013-11-19 20:58:11 +0000, Sylvain wrote:
here it is. with the -v theadtime setting
On 2013-11-20 08:24:06 +0000, Daniel Knobe wrote:
I have additional informations. May be this helps to get this bug fixed.
I played arround with some options and found that if I enable in the developer options: Force GPU-Rendering (Use 2D-Hardwareaccelation in Apps) everthing works nice!
All use cases (see pics) works without a problem with this option on!
Also. How comes this bug did not appear with the common egl ? Maybe HW acceleration was already activated when creating : khronos.egl objets ?
If so, would it be possible that khronos were using implicitly the "windows/view" level solution. ?
On 2013-11-21 16:06:28 +0000, Daniel Knobe wrote:
It works on all levels, this are the options:
<application android:hardwareAccelerated="true" ...>
or
or
getWindow().setFlags(
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
in the onCreate() method.
On 2013-11-22 13:27:16 +0000, Gabriel Jacobo wrote:
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
logcat good 1 (logcat_good_1.txt, text/plain, 2013-11-18 20:48:42 +0000, 5345 bytes)logcat bad 1 (logcat_bad_1.txt, text/plain, 2013-11-18 20:48:58 +0000, 4993 bytes)logcat good 2 (logcat_good_2_and_backound_foreground.txt, text/plain, 2013-11-19 19:55:37 +0000, 26750 bytes)logcat bad 2 (logcat_bad_2_and_backound_foreground.txt, text/plain, 2013-11-19 19:56:36 +0000, 29964 bytes)Reported in version: HG 2.1
Reported for operating system, platform: Android (All), ARM
Comments on the original bug report:
On 2013-11-17 21:53:40 +0000, Sylvain wrote:
On 2013-11-18 00:37:09 +0000, Gabriel Jacobo wrote:
On 2013-11-18 00:50:30 +0000, Daniel Knobe wrote:
On 2013-11-18 07:37:28 +0000, Sylvain wrote:
On 2013-11-18 09:05:37 +0000, Daniel Knobe wrote:
On 2013-11-18 09:07:21 +0000, Daniel Knobe wrote:
On 2013-11-18 09:08:25 +0000, Daniel Knobe wrote:
On 2013-11-18 09:10:17 +0000, Daniel Knobe wrote:
On 2013-11-18 09:16:36 +0000, Sylvain wrote:
On 2013-11-18 09:18:35 +0000, Sylvain wrote:
On 2013-11-18 09:21:01 +0000, Sylvain wrote:
On 2013-11-18 09:26:58 +0000, Daniel Knobe wrote:
On 2013-11-18 09:50:43 +0000, Sylvain wrote:
On 2013-11-18 11:56:13 +0000, Gabriel Jacobo wrote:
On 2013-11-18 20:47:40 +0000, Sylvain wrote:
On 2013-11-18 20:48:42 +0000, Sylvain wrote:
On 2013-11-18 20:48:58 +0000, Sylvain wrote:
On 2013-11-19 08:27:17 +0000, Sylvain wrote:
On 2013-11-19 11:50:44 +0000, Gabriel Jacobo wrote:
On 2013-11-19 12:29:21 +0000, Daniel Knobe wrote:
On 2013-11-19 14:05:41 +0000, Gabriel Jacobo wrote:
On 2013-11-19 19:55:37 +0000, Sylvain wrote:
On 2013-11-19 19:56:36 +0000, Sylvain wrote:
On 2013-11-19 20:07:10 +0000, Sylvain wrote:
On 2013-11-19 20:12:31 +0000, Gabriel Jacobo wrote:
On 2013-11-19 20:56:56 +0000, Sylvain wrote:
On 2013-11-19 20:57:23 +0000, Sylvain wrote:
On 2013-11-19 20:58:11 +0000, Sylvain wrote:
On 2013-11-20 08:24:06 +0000, Daniel Knobe wrote:
On 2013-11-20 09:44:58 +0000, Sylvain wrote:
On 2013-11-20 11:55:53 +0000, Daniel Knobe wrote:
On 2013-11-20 12:07:10 +0000, Gabriel Jacobo wrote:
On 2013-11-20 12:12:04 +0000, Daniel Knobe wrote:
On 2013-11-20 13:00:09 +0000, Sylvain wrote:
On 2013-11-21 16:06:28 +0000, Daniel Knobe wrote:
On 2013-11-22 13:27:16 +0000, Gabriel Jacobo wrote:
The text was updated successfully, but these errors were encountered: