Visible corruption in SDL apps (Neverball, Neverputt) on Nexus 4 / Nexus 7.

Screenshot of neverputt running on Nexus 7 2013.

Screenshot of neverball running on Nexus 7 2013

Ill try to reproduce this. Thanks for the bug report!

Err you say it works fine for other devices? I wonder if its a mir issue rather then SDL...unassigning my self for now :)

The problem could equally be in libsdl2, Unity8 or Mir. So tasks for all until we know which...

Status changed to 'Confirmed' because the bug affects multiple users.

Are these frame dropping clients (swap interval zero) by any chance?

Could just be an adreno driver bug... does the problem happen on non-adreno platforms?

I get similar corruption running Baldur's Gate (via GemRB and SDL2) on krillin. The intro videos play well, but when the main menu appears the shell bleeds into it. The picture clears when you begin to swipe. I'll attach some pics as it is hard to explain.

Begin a right->left swipe and the picture clears

You can work around alpha issues on krillin by masking the alpha channel and clearing the color buffer bit before swapping buffers.

I'm not sure if it's a separate issue or a different symptom of the same issue, but the workaround doesn't help on nexus devices.

OK, with some fiddling I can confirm the same bugs are visible in Mir's demo servers (from package mir-demos). So Unity8 is not a problem.

I can now also see what the problems are:

1. Seeing double: This is SDL incorrectly telling the app that a 16-bit pixel size is supported. It is not supported in Mir.
2. Wrong colours: This is also SDL incorrectly telling the app that it can use 16-bit colour. Mir only supports 24 or 32-bit colour right now.

From gles:

$ env LD_LIBRARY_PATH=./lib/arm-linux-gnueabihf ./gles
Window requested size 640x480, got 768x1280
INFO: Screen bpp: 24
INFO:
INFO: Vendor : Qualcomm
INFO: Renderer : Adreno (TM) 320
INFO: Version : OpenGL ES-CM 1.1
INFO: Extensions : GL_EXT_debug_marker GL_AMD_compressed_ATC_texture GL_AMD_performance_monitor GL_APPLE_texture_2D_limited_npot GL_ARB_vertex_buffer_object GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_type_2_10_10_10_REV GL_OES_blend_equation_separate GL_OES_blend_func_separate GL_OES_blend_subtract GL_OES_compressed_ETC1_RGB8_texture GL_OES_compressed_paletted_texture GL_OES_depth_texture GL_OES_depth24 GL_OES_draw_texture GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_framebuffer_object GL_OES_matrix_palette GL_OES_packed_depth_stencil GL_OES_point_size_array GL_OES_point_sprite GL_OES_read_format GL_OES_rgb8_rgba8 GL_OES_stencil_wrap GL_OES_texture_cube_map GL_OES_texture_env_crossbar GL_OES_texture_float GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_texture_mirrored_repeat GL_QCOM_binning_control GL_QCOM_extended_get GL_QCOM_tiled_rendering
INFO:
INFO: SDL_GL_RED_SIZE: requested 5, got 5
INFO: SDL_GL_GREEN_SIZE: requested 5, got 6
INFO: SDL_GL_BLUE_SIZE: requested 5, got 5
INFO: SDL_GL_DEPTH_SIZE: requested 16, got 16

I've logged the relevant enhancement for Mir in --> bug 1469673. Implementing that enhancement is something we do want to do eventually.

However for now this bug is a bug specifically in libSDL2 where it's telling the app it can do something that it really can't (yet).

There is also a third lesser bug: SDL (or the apps themselves?) fails to respond to resize events.

P.S. The weird transparency is the same bug too. That's just misplaced alpha channel values from the SDL pixel format bug making the compositor (Unity8) turn parts of the SDL surface transparent that should not be.

AFAIK SDL2 should support 24/32 bit colors... I do find that strange since on X11:

INFO: SDL_GL_RED_SIZE: requested 5, got 8
INFO: SDL_GL_GREEN_SIZE: requested 5, got 8
INFO: SDL_GL_BLUE_SIZE: requested 5, got 8
INFO: SDL_GL_DEPTH_SIZE: requested 16, got 24

Im not 100% sure why its failing to get the correct requested size, or rather why mir is not requesting a 24/32bit color. Ill take a look at this! Hopefully that turns out to be the issue. As it seems by default to request a 15/16 bi color

http://hg.libsdl.org/SDL/file/704a0bfecf75/src/video/SDL_egl.c#l242

This is where its getting the gl_config (requested size) then setting the bits internal when it create the egl config. (Also note this is not the same code X11 runs! Since it wont be using EGL)

So it looks like mir is getting the correct requested size (for the most parts a 6 instead of a 5). The main issue is why is it requesting a 5? This could be my fault here for not manually forcing the 24/32 bit or the clients fault for not forcing it. Ill take a deeper look.

Cheers

Hmm, it might be an unavoidable feature of the GL driver on these devices actually (inherited from Android).

If the hardware graphics driver is saying OK to 16-bit pixels then I'm not sure what we can do to stop it. We'd just have to avoid asking for less than 8 bits per channel in SDL, or get around to implementing enhancement bug 1469673.

Mir tries to make it very clear that only 8 bits per channel is supported and forces everyone (including SDL) to choose a 24 or 32-bit pixel format. So it sounds like that's not providing a guarantee that the Android GL driver will actually honour the agreed pixel format.

On that note, I have suspected for a while that Mir forcing clients to choose a pixel format independently of choosing a GL config was redundant and could cause confusion like this. If we can remove one of those steps it would help.

Even simpler: I've attached a Mir branch that replicates the problem (-e5) using just Mir demos. Unfortunately that doesn't relieve SDL from owning the solution to this bug. Because even if Mir added support for 16 bpp formats, SDL would still need to be changed to use it.

I suggest in the shorter term SDL can solve the problem by simply choosing a Mir-compatible EGL config in requesting a minimum of 8 bits per channel:
        EGL_RED_SIZE, 8,
        EGL_GREEN_SIZE, 8,
        EGL_BLUE_SIZE, 8,

But feel free to shame Mir for failing to provide stronger API guarantees that the EGL config actually matches the pixel format in use.

Setting the gl red green, blue and depth sizes from client code (SDL_GL_SetAttribute) doesn't help with the transparency issue on krillin. Does/should this help with the doubling problem on nexus hw? (I don't have any to test)

You mean the colours look right but you have unexpected transparency? If so, that's not entirely unexpected.

The bug for Mir demo servers doing that is bug 1423462. However I have a hunch that Unity8 has the same bug (which has not been officially reported yet). That would not be surprising as it's actually an OpenGL limitation (the right pixel format does not exist in the OpenGL|ES spec) and is slightly awkward to work around.

So there are two possible solutions to that:
  1. Try to make sure your alpha channel (or "x" byte) is always opaque (255) in the app:
       e.g. glClearColor(0.0, 0.0, 0.0, 1.0);
  2. Get the server fixed. Mir demo servers have bug 1423462 open for this. Unity8 has no bug logged against it yet.

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.15.0

Change of heart...

Rather than asking SDL to force 24-bit colour, I've attached a branch that adds support for the required 16-bit pixel formats to Mir. However that won't be enough to declare this bug fixed... SDL still needs updating to use mir_pixel_format_rgb_565 after that is released.

Awesome thank you daniel :). This will land in 0.15? Sooo it'll be a bit hard to get *in* until 0.15 is released, since atm im having to do a pretty large ifndef for 0.13 vs 14.04 mir to push changes upstream.

Worth noting: I have not yet solved the messiness of automatically matching an EGLConfig to its correct MirPixelFormat. That's still something we ask the toolkit (SDL) to do. Some graphics drivers honour the pixel format, and some ignore your chosen pixel format instead assuming they know a better answer from the EGLConfig. It's a mess (one we inherited from Mesa/GBM it seems) and unfortunately remains the responsibility of the toolkit to match up, for now.

Comment #30 is also being resolved... Work in progress in the attached egl-pixel-format branch.

Fix committed into lp:mir at revision 2751, scheduled for release in mir, milestone 0.15.0

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.15.0

This bug was fixed in the package mir - 0.15.0+15.10.20150818-0ubuntu1

---------------
mir (0.15.0+15.10.20150818-0ubuntu1) wily; urgency=medium

  [ Daniel van Vugt ]
  * New upstream release 0.15.0 (https://launchpad.net/mir/+milestone/0.15.0)
    - ABI summary: Only servers and graphics drivers need rebuilding;
      . Mirclient ABI unchanged at 9
      . Mirserver ABI bumped to 33
      . Mircommon ABI unchanged at 5
      . Mirplatform ABI bumped to 9
    - Enhancements:
      . Add support for Mir-on-X11.
      . Latency reduction optimizations (around ~15ms reduction in total):
        Reduced input event resampling latency by 5ms. Reduced output latency
        (in system compositors) by around 10ms with the introduction of
        "predictive bypass". And we're not finished; future Mir releases
        should reduce latency further.
      . Introduced a python3-based Mir performance framework.
      . Lots of preparation for an architectural overhaul of buffer swapping,
        required in the least to support future optimizations like nested
        bypass.
      . Added a new cursor: crosshair
      . Added support for 15/16-bit client pixel formats ("high colour").
      . Added a new client function to make picking the right pixel format
        for a given EGLConfig super simple: mir_connection_get_egl_pixel_format
      . Added application-not-responding detection
      . Added client API for specifying input region shape.
      . Fixed the remaining threading flaws identified by ThreadSanitizer and
        turned it on permanently for all continuous integration in future.
      . Added support for relative pointer motion events (e.g. for gaming).
    - Bug fixes:
      . Fix focus issues breaking autopilot tests entering text (LP: #1468029)
      . Fix mir tests failure on armhf with GCC5 (LP: #1478213)
      . mir_buffer_stream_swap_buffers_sync can hang constraints (LP: #1479899)
      . Loading libmirclient.so twice leads to a segfault in libmirprotobuf.so
        (LP: #1391976)
      . Visible corruption in SDL apps (LP: #1460149)
      . MultiThreadedCompositor::destroy_compositing_threads hangs/deadlocks on
        shutdown or display reconfiguration (LP: #1471909)
      . ctest/"make test" reports 100% tests pass even when some fail.
        (LP: #1472911)
      . Mir server crashed - GLib-CRITICAL **: g_source_get_context: assertion
       'source->context != NULL || !SOURCE_DESTROYED (source)' failed
        (LP: #1473869)
      . USC crash on multimonitor unplug [std::exception::what: error during
        hwc prepare()] (LP: #1474891)
      . [regression] Input focus delay after switching app back into focus
        (LP: #1480654)
      . GLibMainLoopTest.propagates_exception_from_server_action fails with
        GCC 5 in armhf (LP: #1482274)
      . [enhancement] Mir lacks relative mouse support (LP: #1276322)
      . ShmBuffer ignores pixel_format (LP: #1424909)
      . Fullscreen bypassed clients stutter with double buffers when other
        clients are running (LP: #1447896)
      . [regression] Demo servers crash on start-up if MIR_ENABLE_TESTS=OFF
        (LP: #1439078)
      . [regression] The software curs...

Can we close this one? I'm wondering if there is an SDL2 issue left here

It appears the required fix is now in xenial (but not in wily) with 2.0.4+dfsg1-2ubuntu1 -
https://launchpad.net/ubuntu/+source/libsdl2

I haven't tested the new libsdl2 myself, but the source code seems to be doing the right thing now :)

While this is great for Wily, the phones which exhibit this issue are running Vivid, where the issue isn't fixed.

Can the fix please be backported to vivid?

AFAIK, the required Mir bits are in vivid-overlay already. We just need to get the latest libsdl2 into the overlay.

P.S. It's not great for wily at all. The fix is apparently not in wily. Only xenial.