• Locked Locked
  • Replies 7 replies
  • Subscribers 136 subscribers
  • Views 8255 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Dithering on SGS2/Mali400MP

Peter Strand
Note: This was originally posted on 19th June 2011 at http://forums.arm.com

Hi,

I was just investigating a color banding issue in a gles2 application on Samsung Galaxy S II and noticed that GL_DITHER was disabled by default, and could not be enabled either.
Is this a known problem? Intentional? Driver or android/platform issue?

Regards,
Peter
Parents
  • Note: This was originally posted on 20th June 2011 at http://forums.arm.com


    Hi Peter,

    OK I have looked into this and I have a workaround but I need to investigate further.

    Even with the app as it is, I do see dithering between colour levels in screenshots from DDMS:

    Ah, yes, I also se a very subtle dithering now when I run my sample app. Not sure how I missed it before...


    My suspicion is that on other platforms you are requesting RGB565 but getting a higher colour depth returned. The EGL spec allows this, as does Android's setEGLConfigChooser() method.

    Is it possible to trust glGet(GL_XXX_BITS) to give the actual depth of the buffer, rather than the requested?
    (It suggests that I get RGB565 everywhere when I request that from EGL, regardless of the PixelFormat)

    I'll make the egl selection more specific and see what difference that makes..

    Anyway, I definitely see dithering on other platforms.
    Here's a crop from a HTC Desire:




    Leaving the request at 565 but modifying the onCreate() method in SimpleGL.java:


    glView = new GLView(this);
    glView.getHolder().setFormat(PixelFormat.RGBA_8888); // Gives smooth gradient.
    setContentView(glView);


    I still need to investigate whether this addition is correct and necessary, and also your point about glGet() but in the meantime, does this change produce the same results across platforms for you?


    This produces much better results on Mali, and it seems to use the full 888 depth while still subtly dither.
    (at least when looking at gradients)

    On adreno and sgx I get the same result as with a 565 surfaceview (i.e. approx. 565 resolution and strong dither).


    What happens under the surface in this case? Android gives you a 32-bit surface but you render with 16-bit precision and dither - how does that compare performance-wise to just run with 888?

    /Peter
Reply
  • Note: This was originally posted on 20th June 2011 at http://forums.arm.com


    Hi Peter,

    OK I have looked into this and I have a workaround but I need to investigate further.

    Even with the app as it is, I do see dithering between colour levels in screenshots from DDMS:

    Ah, yes, I also se a very subtle dithering now when I run my sample app. Not sure how I missed it before...


    My suspicion is that on other platforms you are requesting RGB565 but getting a higher colour depth returned. The EGL spec allows this, as does Android's setEGLConfigChooser() method.

    Is it possible to trust glGet(GL_XXX_BITS) to give the actual depth of the buffer, rather than the requested?
    (It suggests that I get RGB565 everywhere when I request that from EGL, regardless of the PixelFormat)

    I'll make the egl selection more specific and see what difference that makes..

    Anyway, I definitely see dithering on other platforms.
    Here's a crop from a HTC Desire:




    Leaving the request at 565 but modifying the onCreate() method in SimpleGL.java:


    glView = new GLView(this);
    glView.getHolder().setFormat(PixelFormat.RGBA_8888); // Gives smooth gradient.
    setContentView(glView);


    I still need to investigate whether this addition is correct and necessary, and also your point about glGet() but in the meantime, does this change produce the same results across platforms for you?


    This produces much better results on Mali, and it seems to use the full 888 depth while still subtly dither.
    (at least when looking at gradients)

    On adreno and sgx I get the same result as with a 565 surfaceview (i.e. approx. 565 resolution and strong dither).


    What happens under the surface in this case? Android gives you a 32-bit surface but you render with 16-bit precision and dither - how does that compare performance-wise to just run with 888?

    /Peter
Children
No data