Log in or register to post comments

Why samples use custom EGLCOnfigChooser?

November 14, 2012 - 9:54am #1

Hi, there's most likely a trivial answer to this question but I wasn't able to figure it out by myself. Why samples do use custom EGLConfigChooser instead of basic;

GLSurfaceView.setEGLContextClientVersion(1 or 2); GLSurfaceView.setEGLConfigChooser(red, green, blue, alpha, depth, stencil);

Why samples use custom EGLCOnfigChooser?

November 15, 2012 - 5:52am #4

Hi harism, you are actually right, indeed  the default implementation does not differ that much from the one of the samples

(especially the bit depth criteria are the same as in the custom one, as you correctly pointed out);

still, some little differences are in the way of handling exceptions (e.g. we throw our own IllegalArgumentException in case of failure in finding a config, and other minor things.)

Why samples use custom EGLCOnfigChooser?

November 15, 2012 - 3:08am #3

Hi, I see. I have to admit I'm still a bit puzzled and expected there might be some device related issues causing this design decision. Reading the GLSurfaceView.setEGLConfigChooser API documentation indicates strongly that using "default" config chooser should not differ so much from the custom one after all. It's supposed to select exact color depth match, and at least the desired depth and stencil depths.

Anyway, rationale for asking this is that I once tried to implement my own EGLConfigChooser which did not work on all devices as expected. And though this reminded me of the issue.

Why samples use custom EGLCOnfigChooser?

November 15, 2012 - 2:52am #2

Hi, in the samples we use our own ConfigChooser because that offers a bit more flexibility than using the "standard" approach you refer to;

in particular if you look at the ConfigChooser implementation, you'll notice that we handle the required depth and stencil bit-sizes in a more relaxed way (i.e. no exact match required, but just checking for the "minimum value"), while for the r,g,b,a channels the match is strictly required to be exact.

  In short: the config returned by our ConfigChooser is not necessarily the same as the "default" one (it may vary across devices); we prefer in this case to find our "best config", rather than using the default one.

Log in or register to post comments