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.

Created attachment 1488 [details]
starting testrendercopyex with and without rendering in texture

Created attachment 1489 [details]
taking screenshot testrendercopyex with and without rendering in texture

Created attachment 1490 [details]
starting testgles

Created attachment 1491 [details]
starting testgles2

Created attachment 1492 [details]
open pulldownmenu testrendercopyex with and without rendering in texture

Created attachment 1493 [details]
pressing volume testrendercopyex with and without rendering in texture

I did some more tests with a help of an S3 user.

When the app testrendercopyex starts (with and without drawing in texture) it looks like image: --starting testrendercopyex with and without rendering in texture--.

When I take i screenshot during the app is running the screenshot looks like in image: --taking screenshot testrendercopyex with and without rendering in texture-- But the drawing of the apps stays red like in the image: --starting testrendercopyex with and without rendering in texture--

When the app is running the screens gets normal, when I press a volume button or open the pulldown menu, see image: --open pulldownmenu testrendercopyex with and without rendering in texture-- or --pressing volume testrendercopyex with and without rendering in texture--. When the volumebar or the pulldownmenu disappears the screen looks again like in image: -- starting testrendercopyex with and without rendering in texture--.

Interesting note:
- Open testrendercopyex app
- Press home button once so that the app goes on background
- Hold home button so that it shows running/recently used apps
- Open app and the colors are normal 

The testgles and testgles2 looks ok: --starting testgles-- and --starting testgles2--

Out of many possible issues, it may be a problem with the config chooser code in EGL (SDL_EGL_ChooseConfig), because of the way the colors look...hard to say for sure without some log.

Hopyfully some user will send me a log soon.
One user reported, that he has the issue on a Samsung Galaxy tab 8.0, too.

Having the same issue here for some S3 users. 

from my log I have caught the pixelformat.
current desktop mode: 1280x720@0Hz (SDL_PIXELFORMAT_RGB565)

Please let me know what else I can log. I don't have such a device and would have to wait for users to report anything. But of course I would update my app to include the needed logging. Getting a adb logcat output from such a device would also not be a problem.

works here:
current desktop mode: 800x480@0Hz (SDL_PIXELFORMAT_RGB565)

Galaxy Note 8.0 (kona3g) is affected by this error, too

@Martin, are you using the SDL render functions or calling GLES directly?

If you are testing with testrendercopyex, what about adding:

state->gl_red_size = 8;
state->gl_green_size = 8;
state->gl_blue_size = 8;

...before creating the window?

I'm using the SDL renderer stuff. But I don't think I can execute the test on the users devices. I could only test my apk by handing them over to the user by beta test stage in the google play store. Will add it and report back:

        SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
        SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
        SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);

I tried that and the user report that I didn't change anything.

There was also some more details about the issue. The first few milliseconds (just as long to notice it) the screen is correct. Then it changes to red.

On shutting down the app it's right again for a very short moment.

Hello,

I talked a few days ago with Daniel, and *my* apps worked fine with his user.

@Martin : 

Could you try adding only this attribute before SDL_CreateWindow : 

 SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0);

On some device, I saw the egl-config choosen were a little bit different.


Otherwise, could this commit has an effet https://hg.libsdl.org/SDL/rev/a5f8137ccf01 ?

@Sylvain: I'm already doing this. This is and was my default behaviour.

Created attachment 1501 [details]
Logcat from User S3

An User send me an logcat (see attachment).
He found out another way to get it solved by doing the following steps:
- Open app phone in vertical position
- Flip phone to horisontal position
- press home key once
- hold home key and open the app again

If he don't flip it the app still appears reddish.

Someone an idea?

One of my users also reported the volume buttons "fix". He even managed to keep in in a non-red-version for further playing. But often it's the case the whenever the volume change overlay is gone, that the screen gets red again.

Created attachment 1513 [details]
Logcat from User S3, Android 4.1.2 (Samsung TouchWiz Stock Rom)

I own a S3 now, too. So please let me know what exactly I should log in order to help here.

Btw. when the adsview gets active, the red screen is gone, too and everything looks normal.



D/dalvikvm( 2081): Trying to load lib /data/data/org.caveexpress/lib/libSDL2.so 0x4292b870
D/dalvikvm( 2081): Added shared lib /data/data/org.caveexpress/lib/libSDL2.so 0x4292b870
D/dalvikvm( 2081): Trying to load lib /data/data/org.caveexpress/lib/libSDL2_image.so 0x4292b870
D/dalvikvm( 2081): Added shared lib /data/data/org.caveexpress/lib/libSDL2_image.so 0x4292b870
D/dalvikvm( 2081): No JNI_OnLoad found in /data/data/org.caveexpress/lib/libSDL2_image.so 0x4292b870, skipping init
D/dalvikvm( 2081): Trying to load lib /data/data/org.caveexpress/lib/libSDL2_mixer.so 0x4292b870
D/dalvikvm( 2081): Added shared lib /data/data/org.caveexpress/lib/libSDL2_mixer.so 0x4292b870
D/dalvikvm( 2081): No JNI_OnLoad found in /data/data/org.caveexpress/lib/libSDL2_mixer.so 0x4292b870, skipping init
D/dalvikvm( 2081): Trying to load lib /data/data/org.caveexpress/lib/libSDL2_net.so 0x4292b870
D/dalvikvm( 2081): Added shared lib /data/data/org.caveexpress/lib/libSDL2_net.so 0x4292b870
D/dalvikvm( 2081): No JNI_OnLoad found in /data/data/org.caveexpress/lib/libSDL2_net.so 0x4292b870, skipping init
V/SDL     ( 2081): onResume()
V/SDL     ( 2081): onPause()
V/SDL     ( 2081): surfaceCreated()
V/SDL     ( 2081): surfaceChanged()
V/SDL     ( 2081): pixel format RGB_565
V/SDL     ( 2081): Window size:720x1280
D/SensorManager( 2081): registerListener :: handle = 0  name= LSM330DLC 3-axis Accelerometer delay= 20000 Listener= org.libsdl.app.SDLSurface@429496b0
I/SDL     ( 2081): SDL_Android_Init()
I/SDL     ( 2081): SDL_Android_Init() finished!
I/SDL     ( 2081): external storage state: mounted
I/caveexpress 1.5( 2081): INFO: (LOG_CLIENT) current desktop mode: 720x1280@0Hz (SDL_PIXELFORMAT_RGB565)
E/caveexpress 1.5( 2081): ERROR: (LOG_CLIENT) That operation is not supported (jni/src/client/SDLFrontend.cpp:652 => virtual int SDLFrontend::init(int, int, bool, EventHandler&))
I/caveexpress 1.5( 2081): INFO: (LOG_CLIENT) 720x1280@0Hz SDL_PIXELFORMAT_RGB565
V/SDL     ( 2081): SDL audio: opening device
V/SDL     ( 2081): SDL audio: wanted stereo 16-bit 44.1kHz, 4096 frames buffer
V/SDL     ( 2081): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer

You can try a couple of things...since IIRC this seems to be related to the Render* functions.

1) Try forcing the ES 1.1 renderer, and see what happens
2) Go to GLES_RenderCopy and GLES2_RenderCopyEx and trace the code that selects the source type and then selects a program with GLES2_SelectProgram. If I had to bet, I would say there could be a problem there.

Other than that, experiment to try to narrow the problem down. The best shot at solving this is troubleshooting with the device in hand.

If needed, I can help to build .apk to track down the problem.

@Martin, do you need help for that ? 
Is the red screen always reproducible with your S3 ?

using gles1 works, looks like only gles2 is affected.

will try to debug GLES2_RenderCopyEx now.

oh sorry. Yes, the red screen is always reproducible with my s3 and the gles2 renderer

now also gles1.x has the error again - so both of the gles renderers are affected.

@Sylvain Which apk would you build?

My logging from the rendercopyex function did not yet revealed anything suspicious

@Martin,

I was asking if you needed some help to build/debug the SDL.
But it seems, you know how to do that.

You have the chance to have the device to reproduce your bug, so this is great.

To debug that, I would suggest to see if this is a regression : take an older (10 month old) revision of the SDL, and see if you can get the bug with that version !

nailed it down to SDL_EGL_ChooseConfig. 

Only using this:
    attribs[i++] = EGL_RED_SIZE;
    attribs[i++] = 5;
    attribs[i++] = EGL_GREEN_SIZE;
    attribs[i++] = 6;
    attribs[i++] = EGL_BLUE_SIZE;
    attribs[i++] = 5;
    attribs[i++] = EGL_SAMPLES;
    attribs[i++] = 4;
    attribs[i++] = EGL_NONE;
fixes the problem.

More information as I have more ;)

it really is "only" about wrong values in:
_this->gl_config.red_size, _this->gl_config.green_size and _this->gl_config.blue_size

Setting them manually works. Investigating more.

haha - all in all, it was my own fault.

i have several classes that inherit from each other and i had a typo in one of the derived classes. So for android i also called :

	SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
	SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
	SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);

fixed the typo in the method name of the android specific class and thus not calling SDL_GL_SetAttribute(SDL_GL_*_SIZE, xxx); at all fixes the problem. Let me know whether this also fixed it for you. If you have apks for me to test on my device, let me know, too.

erm. sorry. calling
 	SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 6);
	SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 5);
	SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 6);
in the android glue code. that fixes the problem. I'm not yet sure why a wrong value was picked for this before.

E/SDL/ERROR( 7390): Failed loading eglChooseConfig: Invalid library handle:

the eglChooseConfig is not the reason - another user with a working device just send me this:
Failed loading eglChooseConfig: dlsym library handle is null

with a lot of logging I was able to tackle this issue on my side. My problem was that I was calling SDL_VideoInit manually after calling SDL_Init(SDL_INIT_VIDEO). This leads to overriding the parameters set by SDL_GL_SetAttribute and set them back to the default values. So my RGB565 was ignored. I hope this helps on your side. Make sure to call SDL_Init(SDL_INIT_VIDEO) before doing the SDL_GL_SetAttribute calls and don't call SDL_VideoInit manually.

So SDL sets the parameters wrong on S3 by default. Hopyfully we get this fixed soon!

I don't think the error is in SDL, at least according to what Martin has found.

@Martin, can you figure out why testrendercopyex with the default SDL android project shows this bug as well?

SDL is not setting wrong values - it does not set any value by default as far as I can see.

And it looks like the S3 is really picky about the values there - setting anything else than RGB656 doesn't seem to work.

@Gabriel: The problem is that SDLTest_CommonCreateState does not set 656, but 332 - which the S3 can't handle. Setting this to 656 will do the trick.

Btw. is there a way to determine this before the window is created? I get the correct pixel format for the display modes of the window - but I would need it earlier to the the rgb sizes. This isn't possible, as the function would require a window pointer ;)
Did I miss something?

anything new here? has anyone an advice how to fix it properly without hardcoding the color sizes?

@Martin, 
on my apps, I don't hardcode the color size. And I think I got no problem on S3.
(maybe you can double check my apps on your S3)

I call : 

SDL_Init(SDL_INIT_VIDEO)
SDL_Init(SDL_INIT_AUDIO)  
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0);
SDL_GL_SetAttribute(SDL_GL_RETAINED_BACKING, 0);
SDL_CreateWindow
SDL_CreateRenderer

Notice that SDL_VideoInit internally set {red, green, blue}_size at (3,3,2)
which should be sent to eglChooseConfig to get an optimal config.

Maybe you need to dump:
- the egl config asked (before calling eglChooseConfig)
- all the egl configuration available + print the "bitdiff" (see SDL_egl.c)
- the egl config actually selected 


@Gabriel, 
I see the "depth_size" is by default "16".
and, I have seen sometimes this case.
application request by default (red_size, green_size, red_size, depth_size)
(3,3,2,16)
the closest is (3,3,2,18) which appears to be very slow.
but a better one (4,4,4,16) is then not selected.

Sometimes, I saw a weight of 10 is affected on the "objective function" to select the optimisal config.

I have seen also there is an attribute  EGL_SLOW_CONFIG that could be usefull :)

The Galaxy Note 2 (Android 4.3) has the problem, too. :-/

My intuition tells me this is a problem with the GLES2 shaders. Let's say you don't define the RGB size and end up with a 332 for the screen, what texture format are you using? SDL_RenderCopy/Ex needs to determine the right shader to blit the texture correctly (and map the colors correctly as well if you are mixing, for example, ARGB with RGBA), and this is probably failing.

So, to better figure this out, it may be useful to let SDL choose the 332 format for the screen, make a note of what texture format you are using, and see what shader gets picked via GLES2_SelectProgram. Then, try playing with that shader to figure out what needs to be fixed.

I'm just guessing here, but it may very well be that other devices don't support a 332 format (or whatever ends up being picked by SDL), and that's why we don't see the problem more often.

Nothing new about that problem?

Sylvain was right:
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0);
fixes the problem. Really strange.

@Martin, what about you? does this fix your red-screen too ? can you double-check ?

@Gabriel, I think Daniel does not use shaders but maybe Martin does 

@Daniel :

I think we should not let something strange get fixed like this.
I try to explain my guess ( but Gabriel is the expert:) ) : 

There are several different opengl "configs" available on each device.
And one configuration has to be choosen/set to start rendering !

You choose your configuration by giving a set of parameter (size of depth, red, green, blue, and so on),
and finding the closest matching configuration available on the device.

SDL has already a set of default parameters. 
But, in your Game/Application you can override them (with the SDL_GL_SetAttribute() calls!).

SDL uses its default parameters, your requirements, and find the closed opengl configuration available : 

There are two ways to do that : 
1/ Easy way : use an API to ask the closest matching configuration
2/ Manual way : browse all configurations, compute for each configuration an "absolute error", and in the end, select the configuration with minimum error.
(The "absolute error" is the sum of all the absolute value of differences between the required value and the available (currently browsed) config.  It always increase as the browsed config gets different, so selecting the one with minimun error mean finding the closest matching).

Historically we were using (2) in Java language, then (1) in C language, then (2) in C language.

Often, there is already a perfect match so it works!
Sometimes a near match is found but it can :
- be very slow (happens to me on some devices because depth-18 was choosen)
- produce red-screen like on your device (could this be a SDL bug?)
- and also work correctly :)


Then : 

- I dont know if (1) method is perfect.
	
- Method (2) is tricky because "depth" can have value from 0->18 (?maybe more?).
   whereas "color_size" can go from 3->8
   So, depend on available configs, you can compromise all the color sizes not to have penalties on depth ! Which may be bad !

- There could be weights to make the choice more realistic. Pelya does that : 
https://github.com/pelya/commandergenius/blob/sdl_android/project/java/GLSurfaceView_SDL.java (line 700)


Maybe : 
- you could dump all configs inside SDL code (with basic prinfs in SDL_egl.c).
so that we understand : what configuration is asked, what configuration are available, and which one get choosen.

(Also, with your parameters, what method (1) would have choosen ?)

- With this information, maybe we could try to set the same context that is choosen on your device and understand why SDL is making a red-screen. Maybe there are some format conversion function missing in SDL.

Cheers.
Sylvain

For me its not possible to check all that stuff :-/, because I'm not owning an affected Samsung device. Is there somebody else how can do that? Martin?

This bug is a showstopper for me, because I need to allocate a depth buffer on Android devices and, if I'm reading this thread correctly, the workaround for this S3 issue is to avoid allocating a depth buffer...

ardi, 
I am note sure "depth" buffer is missing.
It's more like "we ask to eglConfig a *config* no depth buffer, to solve the red screen issue."
Maybe there are configurations with depth buffer, that are working.

Do you have a Samsung S3 ?

FWIW, I just tried testrendercopyex and testgles2 on a 2014 Samsung Galaxy Tab 12, and both worked perfectly.

I guess I'll add my 2 cents.

The same red tint is happening in OpenXcom android port on some Samsung devices (see http://openxcom.org/forum/index.php?topic=1864.msg16739#msg16739 for an example), and the solution is to disable hardware overlay in developer settings.

OpenXcom uses SDL1.2 and renders to a SDL_Surface, the Android port uses SDL2 and uploads the contents of that SDL_Surface to a SDL_Texture. I get the same effect if there's a mismatch between [RGBA]masks of the surface and pixelformat of the texture (i.e. if I set masks for ARGB8888 and texture's pixelformat is RGBA8888). Unfortunately I don't have a Samsung device, so I can't confirm if setting format to RGBA8888 solves the problem (and if it's something in the Samsung's Android implementation that forces texture pixelformat).

Hope this helps!

Can anyone with access to a S3 or other of the affected devices print the output of the config selection loop in SDL_EGL_ChooseConfig ? (It's the loop that starts on line 363 of SDL_egl.c)
If we get a complete dump of the modes with SDL_GL_DEPTH_SIZE==0 and SDL_GL_DEPTH_SIZE!=0 and what ends up being selected we may gain some insight into what's going on here.

I did some research on the pixel formats of the native surface, it seems a ARGB format is not available, so that should not (in theory) be the problem.

Also, if you have better ideas (or patches!) to improve the very crude config selection that we do to select the best configuration, they'll be most welcome!

Created attachment 1721 [details]
patch dump of egl params

No access to S3 ..

but, here's a patch for "SDL_egl.c" to dump all configs + the attribs requests.

Easy to activate for someone who wants to use it : just uncomment the DEBUG_EGL_CONFIG.

I will try that patch and post the output. Imo this patch should go upstream. And maybe it should get activated by a hint or something like that. That way we could get the data even from users without recompiling anything.

got a segfault in Android_JNI_GetTouchDeviceIds - will investigate

Martin, yep, that would be great.

Also, Here's a new version of the patch so that the "value" of each attrib is also converted to a string.

Created attachment 1722 [details]
patch dump of egl params

I will post the data from the updated patch. But first I have to get my head around this strange segfault. The mid is NULL - really strange, because it's definitely there in the java file. But I'm on it - must be some local build env error.

btw. this might help, too:
http://stackoverflow.com/questions/10758975/how-can-i-create-an-egl-context-
from-a-native-function-when-the-nativewindowtype

examples:
https://github.com/bkaradzic/bgfx/blob/master/src/glcontext_egl.cpp
https://github.com/floooh/oryol/blob/master/code/Modules/Render/egl/eglDisplayMgr.cc

I will try both on my S3 to see whether it works with those libs - but of course first SDL with the latest patch.

It may be worth adding ANativeWindow_setBuffersGeometry if it fixes the problem...can you try it?

I will try it of course, too. I should have the time today to test all the stuff. Will report back.

Created attachment 1726 [details]
dump of egl variables

the testgles works fine on my S3 now (also no red screen there). But i'm also not sure whether the test was ever broken. For my app this only happened after a second call to SDL_InitVideo (see my comments above)

testgles was never broken. Only testrendercopyex has the redscreen.

Created attachment 1727 [details]
dump of egl variables for rendercopyex test

@Gabriel - is there a hint on to include the bitmaps in the apk with the android build script? I can't find it. I'm not sure whether the current egl vars are useful, because the test doesn't work without the sprites loading.

Let me know if this fixes it: https://hg.libsdl.org/SDL/rev/c30e826412d1

Otherwise we may try requesting a config with EGL_NATIVE_VISUAL_ID == 7 on Android.

Thanks a lot for all this effort. I don't have an S3 for testing, but I need that this bug is fixed for targetting Android. So, thanks a lot, and I hope the patch by Gabriel fixes it. I'm following the findings on this bug. Thanks a lot.

@Martin, did you get a chance to test the fix?

@Gabriel: See my comment from 2014-07-03 12:15:31 UTC 

I didn't had the time to fix or extend the build script or to do it manually. If there is an automated way, please let me know - otherwise I will try to copy the bitmaps manually and rebuild the apk manually. But that might take soem time.

After the build script finishes and before running "ant debug install", just create an "assets" folder and copy every *.bmp file from test there.

unfortunately the proposed fix doesn't fix it.

not sure whether it was mentioned before - but the first frame(s) look(s) fine.

the error is definitely in SDL_EGL_ChooseConfig for ( i=0; i<found_configs; i++ ) { ... }

if i do:

    if (_this->egl_data->eglChooseConfig(_this->egl_data->egl_display, attribs, &_this->egl_data->egl_config, 1, &found_configs) == EGL_FALSE || found_configs == 0) {
        return SDL_SetError("Couldn't find matching EGL config");
    }
    return 0;

it works perfectly.

just doing this:

        if (bitdiff < best_bitdiff || best_bitdiff == -1) {
            _this->egl_data->egl_config = configs[0];
            
            best_bitdiff = bitdiff;
        }

works perfectly, too.

so it "just" picks the wrong config

Yes, we need to know why. That's what this whole exercise is about :)

if this behaviour with the bitdiff is really needed - then maybe there should be a hint to disable it. as far as i know eglChooseConfig will always return at least the requested type - but maybe higher values - in our case we e.g. request 565 and get 888 - which has a higher diff than the format we requested. it's still weird that the mode we finally requested isn't working.

btw. the bestdiff stuff is also weird because it doesn't really take into account that there might be several modes with the same diff - which one is better then?

I/SDL/APP (20206): Dump config 8
I/SDL/APP (20206): {
I/SDL/APP (20206):   EGL_ALPHA_SIZE => 4
I/SDL/APP (20206):   EGL_ALPHA_MASK_SIZE => 0
I/SDL/APP (20206):   EGL_BIND_TO_TEXTURE_RGB => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (20206):   EGL_BIND_TO_TEXTURE_RGBA => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (20206):   EGL_BLUE_SIZE => 4  ******* (requested=2, diff=2)
I/SDL/APP (20206):   EGL_BUFFER_SIZE => 16
I/SDL/APP (20206):   EGL_COLOR_BUFFER_TYPE => EGL_RGB_BUFFER (12430 == 0x0000308e)
I/SDL/APP (20206):   EGL_CONFIG_CAVEAT => EGL_NONE (12344 == 0x00003038)
I/SDL/APP (20206):   EGL_CONFIG_ID => 21
I/SDL/APP (20206):   EGL_CONFORMANT => 0x00000005 (5 == 0x00000005)
I/SDL/APP (20206):   EGL_DEPTH_SIZE => 24  ******* (requested=16, diff=8)
I/SDL/APP (20206):   EGL_GREEN_SIZE => 4  ******* (requested=3, diff=1)
I/SDL/APP (20206):   EGL_LEVEL => 0
I/SDL/APP (20206):   EGL_LUMINANCE_SIZE => 0
I/SDL/APP (20206):   EGL_MAX_PBUFFER_WIDTH => 4096
I/SDL/APP (20206):   EGL_MAX_PBUFFER_HEIGHT => 4096
I/SDL/APP (20206):   EGL_MAX_PBUFFER_PIXELS => 16777216
I/SDL/APP (20206):   EGL_MAX_SWAP_INTERVAL => 10
I/SDL/APP (20206):   EGL_MIN_SWAP_INTERVAL => 0
I/SDL/APP (20206):   EGL_NATIVE_RENDERABLE => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (20206):   EGL_NATIVE_VISUAL_ID => 7
I/SDL/APP (20206):   EGL_NATIVE_VISUAL_TYPE => 0
I/SDL/APP (20206):   EGL_RED_SIZE => 4  ******* (requested=3, diff=1)
I/SDL/APP (20206):   EGL_RENDERABLE_TYPE => 0x00000005 (5 == 0x00000005)  ******* (requested=4, diff=1)
I/SDL/APP (20206):   EGL_SAMPLE_BUFFERS => 0
I/SDL/APP (20206):   EGL_SAMPLES => 0
I/SDL/APP (20206):   EGL_STENCIL_SIZE => 8
I/SDL/APP (20206):   EGL_SURFACE_TYPE => 0x00000405 (1029 == 0x00000405)
I/SDL/APP (20206):   EGL_TRANSPARENT_TYPE => EGL_NONE (12344 == 0x00003038)
I/SDL/APP (20206):   EGL_TRANSPARENT_RED_VALUE => -1
I/SDL/APP (20206):   EGL_TRANSPARENT_GREEN_VALUE => -1
I/SDL/APP (20206):   EGL_TRANSPARENT_BLUE_VALUE => -1
I/SDL/APP (20206): }
I/SDL/APP (20206): bitdiff = 12
I/SDL/APP (20206): New best bitdiff = 12 !

this is the mode i finally get

I/SDL/APP (16088): Dump config 0
I/SDL/APP (16088): {
I/SDL/APP (16088):   EGL_ALPHA_SIZE => 0
I/SDL/APP (16088):   EGL_ALPHA_MASK_SIZE => 0
I/SDL/APP (16088):   EGL_BIND_TO_TEXTURE_RGB => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (16088):   EGL_BIND_TO_TEXTURE_RGBA => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (16088):   EGL_BLUE_SIZE => 8  ******* (requested=5, diff=3)
I/SDL/APP (16088):   EGL_BUFFER_SIZE => 32
I/SDL/APP (16088):   EGL_COLOR_BUFFER_TYPE => EGL_RGB_BUFFER (12430 == 0x0000308e)
I/SDL/APP (16088):   EGL_CONFIG_CAVEAT => EGL_NONE (12344 == 0x00003038)
I/SDL/APP (16088):   EGL_CONFIG_ID => 32
I/SDL/APP (16088):   EGL_CONFORMANT => 0x00000005 (5 == 0x00000005)
I/SDL/APP (16088):   EGL_DEPTH_SIZE => 24  ******* (requested=16, diff=8)
I/SDL/APP (16088):   EGL_GREEN_SIZE => 8  ******* (requested=5, diff=3)
I/SDL/APP (16088):   EGL_LEVEL => 0
I/SDL/APP (16088):   EGL_LUMINANCE_SIZE => 0
I/SDL/APP (16088):   EGL_MAX_PBUFFER_WIDTH => 4096
I/SDL/APP (16088):   EGL_MAX_PBUFFER_HEIGHT => 4096
I/SDL/APP (16088):   EGL_MAX_PBUFFER_PIXELS => 16777216
I/SDL/APP (16088):   EGL_MAX_SWAP_INTERVAL => 10
I/SDL/APP (16088):   EGL_MIN_SWAP_INTERVAL => 0
I/SDL/APP (16088):   EGL_NATIVE_RENDERABLE => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (16088):   EGL_NATIVE_VISUAL_ID => 2
I/SDL/APP (16088):   EGL_NATIVE_VISUAL_TYPE => 0
I/SDL/APP (16088):   EGL_RED_SIZE => 8  ******* (requested=5, diff=3)
I/SDL/APP (16088):   EGL_RENDERABLE_TYPE => 0x00000005 (5 == 0x00000005)  ******* (requested=1, diff=4)
I/SDL/APP (16088):   EGL_SAMPLE_BUFFERS => 0
I/SDL/APP (16088):   EGL_SAMPLES => 0
I/SDL/APP (16088):   EGL_STENCIL_SIZE => 0
I/SDL/APP (16088):   EGL_SURFACE_TYPE => 0x00000407 (1031 == 0x00000407)
I/SDL/APP (16088):   EGL_TRANSPARENT_TYPE => EGL_NONE (12344 == 0x00003038)
I/SDL/APP (16088):   EGL_TRANSPARENT_RED_VALUE => -1
I/SDL/APP (16088):   EGL_TRANSPARENT_GREEN_VALUE => -1
I/SDL/APP (16088):   EGL_TRANSPARENT_BLUE_VALUE => -1
I/SDL/APP (16088): }
I/SDL/APP (16088): bitdiff = 17
I/SDL/APP (16088): New best bitdiff = 17 !

this is the mode that works

What if we just say - if we get a mode that has a diff of 0 => pick it - otherwise just choose the first one. I've checked the other two projects i've linked earlier and both are working - both just take the first returned config.

Created attachment 1741 [details]
proposed patch to fix the issue

This fixes the issue for me - tested on S1, S2 and S3 (only S3 was affected - but I wanted to make sure that it still works on the others)

I don't think selecting the first config available is the solution here though it may fix this particular issue. We can modify the selection algorithm though, suggestions on that are welcome.

It looks like the source of problems is with EGL_NATIVE_VISUAL_ID and maybe EGL_NATIVE_VISUAL_TYPE. Can you try adding a EGL_NATIVE_VISUAL_ID==7 (or some other value) to the bitdiff logic and see if that makes the algorithm select a valid choice?

I don't have any other suggestion than that - just judging from all the engines I've digged in order to see how they are doing it - and of course from the fact that the selection is already done as good as it could be.

According to e.g. blackbarry docs [1] (and also some others), it's fine to just pick the first one.

I'm not sure what exactly speaks against this in the SDL context - can you explain?

[1] http://docs.blackberry.com/en/developers/deliverables/17967/Configure_EGL_1232264_11.jsp

yes - will try to do the EGL_NATIVE_VISUAL_ID stuff

SDL_Log("eglGetConfigAttrib(EGL_NATIVE_VISUAL_ID) => %i - original value was: %i\n", format, ANativeWindow_getFormat(nw));

this gives 7 with original value of 4

if i skip EGL_NATIVE_VISUAL_ID 7 i get a working mode (555)

the original mode of 4 works fine. so (at least for android) it would also be a valid fix to choose the config that has the EGL_NATIVE_VISUAL_ID set to ANativeWindow_getFormat(nw)

Hi!  See in the dump log the "request = " this is the *asked* parameters.
Config_8 (not working) and Config_0 (working) have been obtained by requesting difference set of parameters : 
r/g/b/depth = 3/3/2/16 for Cfg0 and  5/5/5/16 for Cfg8.

is that correct or did the "attrib[]" table is changing wrongly? because this is use for the BitDiff !


Also. A SDL question : once we got a Config, why dont we never tell SDL about the retrieved configuration. Isn't it necessay for interna Format conversion ?

Hey,

So I got a S3. I have updated to the latest trunk. I am able to reproduce the bug with my applications.

What happens:

  The screen is blinking once red each time SDL_RenderPresent() is called.

Adding: 

  SDL_GL_SetAttribute(SDL_GL_RETAINED_BACKING, 0);

solves this issue.

(the call to ANativeWindow_setBuffersGeometry is done, but that does not solve the issue).

A possible solution I was toying with was getting (for Android only) the pixel format with is filtering the configs selecting those that match the native format returned by ANativeWindow_getFormat. I'll get a patch at some point done, but feel free to try that idea out in the meantime.

Created attachment 1764 [details]
dump of config ok, and error.

Here's dump a config OK and BlinkRed.
the only difference what done by asking a depth of 0.

I will look at ANativeWindow_getFormat after! thanks.
but the bug look very strange : it just blinks red once each SDL_RenderPresent, then the display is absolutely correct.

ANativeWindow_get format gives a relevant value after the config has be set.

in my previous example, when the good config is set, the format is 4.
For the blink red config, the format is 7.

 29 enum {
 30     WINDOW_FORMAT_RGBA_8888          = 1,
 31     WINDOW_FORMAT_RGBX_8888          = 2,
 32     WINDOW_FORMAT_RGB_565            = 4,
 33 };

Created attachment 1765 [details]
Samsung S3 spreadsheet

Here's a spread sheet with all configurations of the galaxy S3.
I tried the 19 configs: 
- three of them are broken with a red screen blinking (21/22/23)
- one is broken with the screen reverse + shift of colors (40)
- and others are working correctly.

All the red-screened configs have a EGL_NATIVE_VISUAL_ID of 7. And there are the only one to have this value of 7.
And the other (40) one has a wrong(?) EGL_NATIVE_VISUAL_ID (842094169).

This EGL_NATIVE_VISUAL_ID also seems to be the same value returned from ANativeWindow_geFormat.

A solution would be to had a penalty to EGL_NATIVE_VISUAL_ID of 7 (not to discard those configs absolutely). 

  _this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_NATIVE_VISUAL_ID, &value);
  if (value == 7)
  {
     bitdiff += 1000;
  }

Maybe this happens on other phones? 
My HTC has no config of visual id 7.

A few updates : 

* A mistake in one of my previous message : ANativeWindow_getFormat() returns a value of "4" before choosing any egl-config on the S3.
So we could filter the configs with this value. That would solve the samsung S3 issue, but we would also discard some working config and could produce bug on other hardware.

* I have tried an android 2.3.3 motorola defy, and a nexus7. All configs are working,
the 'defy' has a few slow configs that are correctly displaying but unusable though.

* According to http://developer.android.com/reference/android/app/NativeActivity.html
EGL_NATIVE_VISUAL_ID is an attribute of the EGLConfig that is guaranteed to be accepted by ANativeWindow_setBuffersGeometry().
But this is not always the case. On the S3, one problematic EGL_NATIVE_VISUAL_ID has a value 842094169 (and not working).
I think, I saw on the motorolla a EGL_NATIVE_VISUAL_ID of 8 (but working correctly).

We can had "big" penalties to sort out the problematic configs, without discarding them totally. A big enough offset so that it cannot be catch-up by small diff.
The problematic configs would be choosen only if no working config are avaiblable.

something like : 


  _this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_NATIVE_VISUAL_ID, &value);
  if (value == 1 || value == 2 || value == 4)
  {
     // no penalty, most usual case. So we should select those configs first!
  }
  else if (value == 7)
  {
     // Biggest penalty. Samsung S3
     bitdiff += 5000;
  }
  else if (value > 7)
  {
    // ? Also big penalty ?
  }
  else
  {
     // Medium penalty for intermediate. (because format is bitmask?) 
     bitdiff += 500;
  }

  _this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_CONFIG_CAVEAT, &value);
  if (value == EGL_SLOW_CONFIG)
  {
     // Medium penalty. 
     bitdiff += 500;
  }

This is all work arounds to what seems to me a problem in the custom Android that Samsung is shipping (there's reports that this issues does not happen with Cyanogen). I wouldn't hardcode a value of 7 (which seems an OR'ed value of the 3 pixel formats), instead we can either prioritize or just only select those formats that have EGL_NATIVE_VISUAL_ID == ANativeWindow_getFormat.

Or we can just embrace the workaround nature of this and apply this extra logic (or whatever funky logic we come up with) only for these models:

#include <sys/system_properties.h>
char model_string[PROP_VALUE_MAX+1];
__system_property_get("ro.product.model", model_string);

Ref: https://groups.google.com/forum/#!topic/android-ndk/UP5v_S0BDdY

This also seems to me a problem of the samsung S3 Android. For the S3, but maybe also for other samsung models.
(Sure about cyanogen? could all configs be tried?)

Maybe testing all configs on other could unveil some problems.

I agree hardcoding a penalty of 7 for Samsung S3 is not a great idea.
But I wouldn't add code to match a specific model neither (to many models to cover).

I agree, to prioritize (but not to filter others !) :

EGL_NATIVE_VISUAL_ID == ANativeWindow_getFormat.

but I would still had :

  _this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_NATIVE_VISUAL_ID, &value);

  if (EGL_NATIVE_VISUAL_ID == ANativeWindow_getFormat)
  {
     // no penalty, we match the native format
  }
  else if (value == 1 || value == 2 || value == 4)
  {
     // single format (but not ANativeWindow_getFormat)
     // small penalty
     bitdiff += 1000;
  }
  else if (value & ~7 == 0) 
  {
     //a few formats
     // medium penalty
     bitdiff += 2000;
  }
  else
  {
     // out of bounds
     // big penalty
     bitdiff += 3000;
  }

  // Penalty for slow config
  _this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_CONFIG_CAVEAT, &value);
  if (value == EGL_SLOW_CONFIG)
  {
     // Medium penalty. 
     bitdiff += 1000;
  }

 1, 2, 4 and 7 to be replaced by 
 ( WINDOW_FORMAT_RGBA_8888, WINDOW_FORMAT_RGBX_8888, WINDOW_FORMAT_RGB_565 )


* Also... What if this wasn't a problem of S3 but a bug in SDL Render?
Could I run an egl app with SDL without the SDL renderer?

I have tried the SDL testgles2 : 
when I force one of the config with format=7 of the S3, I get a red tinted cube on the screen. If I had also a SDL_Delay after the SwapWindow I get the red blinking effect. 
So, this is exactly what I observed previously with SDL renderer.


I have tried to reduce the testgles2 to a basic testcase : 
- no shader, not even creation of shader.


     SDLTest_CommonInit / SDL_GL_CreateContext / LoadContext
     ...
     SDL_GL_MakeCurrent(state->windows[0], context[0]);
     while (1)
     {
         GL_CHECK(ctx.glClearColor(0.0, 0.0, 0.0, 1.0);
         GL_CHECK(ctx.glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT)));
         SDL_GL_SwapWindow(state->windows[0]);
         SDL_Delay(100);
     }   

This also produce a red blinking screen before coloring to black.
Maybe this egl config is somehow similar to *debug* mode existing on some device ?

I have no more idea about this issue! let me know if you want more information with this S3.

Can you let me know the output of:

#include <sys/system_properties.h>
char man[PROP_VALUE_MAX + 1], mod[PROP_VALUE_MAX + 1];
int lman = __system_property_get("ro.product.manufacturer", man);
int lmod = __system_property_get("ro.product.model", mod);

yes, it's: 

I/SDL/APP (13320): lman=7 man=samsung
I/SDL/APP (13320): lmod=8 mod=GT-I9300

Also, the samsung device has just been factory reset.
Android version = 4.3

Again, let me know if you need more information before I give back the S3.

Someone seems to have the red-screen issue on other devices: https://bugzilla.libsdl.org/show_bug.cgi?id=2653
So I wouldn't go for specific patch to samsung s3.

Created attachment 1783 [details]
possible patch

I've a S3  and the red screen issue.  I think I know the problem.
The problem is, please correct me if it's wrong, that  the pixelformat (determined by Java "surfaceChanged") was not supplied into gl config, so gl pixelformat is RGB332 (default value). It seams that a S3 can't use RGB332.
I added into Android_VideoInit() some changes which sets color sizes. And I disabled overwriting color sizes in SDL_test_common.c when compiling for Android. This solved it on my S3.

Looks interesting: it makes sense that the java pixel format should be sent to eglChooseConfig to find the appropriate config.

I believe this makes the red-screen disappear because you reduced the number of config retrieved by eglChooseConfig !

Especially, because the config that are problematic are RGBA == 4444 (CONFIG_ID = 21, 22, 23).
and that you are requesting config > 565. (eglChooseConfig could give configs greater than requested)

(But maybe your patch is the good solution !)


It would be nice to try to things differents : 

- try your patch + explicitly force one of the bad EGL config (use the debug patch to have outputs!).
(I usually patch SDL_egl.c, attrib[0] = EGL_NONE to have all config browsed)
=> I am almost sure you'll get the red-screen


- try your patch + explicity force one of the bad EGL config, and try to request explicitly a surface RGB_4444 in java : 

see http://stackoverflow.com/questions/8829943/how-to-find-the-best-pixelformat-for-an-android-surfaceview

public void surfaceCreated(final SurfaceHolder holder) {
...
    holder.setFormat(PixelFormat.RGBA_4444);
...
}

=> I would be curious to see if the screen is still red !

You're right,the screen is still red with a RGBA4444 config.
I wrote a little Java App which tests these configs in a GLSurfaceView - the screen is red too.
I think these configs are not ok, maybe we can't solve it completely, but with my patch RGB565 and RGBA8888 works now.

Just a confirmation, When you said you have the red blinking screen with RGB_4444.
Can you confirm you have added the java line 
"holder.setFormat(PixelFormat.RGBA_4444);" ??

like in:
 http://stackoverflow.com/questions/8829943/how-to-find-the-best-pixelformat-for-an-android-surfaceview

I confirm, I've added these line. The screen is still red.

I experienced the issue in these devices and had worked around that.

Basically the issue is that in those devices, 1555 rendering is broken, so I needed to avoid rendering in 1555.
By default, SDL is looking for best optimal render target closer to 332, which is 1555.
By setting RT format to 565 (or 888), it worked fine in these devices.

  // Set back buffer format to 565
  SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
  SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
  SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

I'm also experiencing this problem.
I'm also confused.
After all this comments I'm nto sure if there's a good workaround for this or not.

1)This was suggested. Have someone else tryed this out? And:
Where should I place this calls?
After SDL_Init(SDL_INIT_VIDEO)?

  SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
  SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
  SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

2) How about this:
https://bugzilla.libsdl.org/attachment.cgi?id=1741&action=diff

Is it safe to use any of this methods?

I did this:

  SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
  SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
  SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

After creating the rendering and it solved the problem on the faulting device. It doesn't seem to have broken the other devices.

Correction to the previous post: it's not after, it's before creating the renderer.

The issue also occurs on (Lenovo) Motorola G4 Plus phones running Android 6.0.1.

Requiring a R8G8B8 backbuffer solves the issue by never selecting the broken A1R5G5B5 mode:

SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);

This needs to be done before creating the renderer

@Emmanuel Thanks for the info. In the meantime, I got news issues and I just wondering if this could not be solved by using the flags "SDL_RENDERER_PRESENTVSYNC".

@Emmanuel

Just wondering: you solved that issue but requiring a R8G8B8 backbuffer.
On your device, what is the log of the java function "surfaceChanged()". It somehow requires a pixel format, do you know which one ?

I removed the 565 GL_Attribute lines and for me the red screen problem on my Samsung Galaxy Note didn't reappear. Must have been already fixed with SDL 2.0.4, can't reproduce it with this version either.

So is this issue resolved at this point, or are we still having problems on some reasonable devices?

--ryan.

I am sure there are still issues with those phones (S3, ..).

But that got resolved by adding / forcing:

    SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
    SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
    SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);


Maybe, we only need to update README-android.txt with this advice, or set different default rgb values for Android (SDL default is 332 from SDL_GL_ResetAttributes()).


I personally think we could also remove the "bitdiff" in SDL_egl.c, which tries to find the best config whereas there are already sorted.

https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglChooseConfig.xhtml

"When more than one EGL frame buffer configuration matches the specified attributes, a list of matching configurations is returned. The list is sorted according to the following precedence rules, which are applied in ascending order (i.e., configurations that are considered equal by a lower numbered rule are sorted by the higher numbered rule): ..."So: 

At best SDL bitdiff does nothing by selected the first, otherwise it does worse : it unsorts the config list.

I experienced a blue tinting of my SDL2 Android app on an LG G7 ThinQ.  I'm using SDL 2.0.8.

Thanks to the tips in this bug report, I was able to work around it with this code:
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

It had to be before the SDL_CreateWindow call for it to work.  My Moto X Pure Edition and Samsung Galaxy Nexus phones never had the problem and continued to have proper coloring after this change.

The G7 is a new phone so I think it's safe to say these tinting issues are still a problem.

I can confirm the problem with the G7 ThinQ.

(In reply to Sylvain from comment #112)
> I personally think we could also remove the "bitdiff" in SDL_egl.c...
> At best SDL bitdiff does nothing by selected the first, otherwise it does
> worse : it unsorts the config list.

Has this now been actioned?  If not, what are the remaining concerns?

I undid the workaround to prevent blue tinting on LG G7 ThinQ and the display looks fine now. Built with SDL 2.0.12. The phone is running Android 9 and has probably been upgraded since I first reported the problem so who knows what fixed it.