EGL 1.4 config sort rule 3 (component sizes)

The EGL 1.4 spec’s config sort rule 3 for component sizes is counter-intuative. However, I think the foot note (foot note 6) on page 24 should make it clearer that this is really, really odd behaviour. Currently it reads:

“This rule places configs with deeper color buffers first in the list returned by eglChooseConfig.
Applications may find this counterintuitive, and need to perform additional processing on the list of
configs to find one best matching their requirements. For example, specifying RGBA depths of 5651
could return a list whose first config has a depth of 8888.”

I think it should use the example where there is an RGBA5650 and RGBA8888 config and the application has specified 1110, as this will also return the RGBA8888 config first. I also think it should be noted that the entire sort rule can be skipped by specifying 0 or EGL_DONT_CARE for the individual buffer sizes. In that case, the implementation will then drop to the 4th sort rule which puts configs with smaller EGL_BUFFER_SIZE higher up in the list, which I think is the more natural sort order. In fact perhaps that should be made a recommendation as this sort rule leads to a great deal of confusion. IMHO, it’s a broken part of the spec.

“This rule places configs with deeper color buffers first in the list returned by eglChooseConfig. Applications may find this counterintuitive if they expect configs with smaller buffer sizes to be returned first. For example, if an EGL implementation has two configs with RGBA depths of 8888 and 5650 and the application specifies RGBA 1110, the implementation will return the 8888 config first. To avoid this rule altogether, an application can specify 0 or EGL_DONT_CARE for each component size, in which case the EGL implementation will drop to the next rule which puts configs with a smaller EGL_BUFFER_SIZE higher up in the list.”

In retrospect I think all of the mobile IHVs would agree with you :slight_smile: This behavior was inherited from GLX, which was the starting point for the EGL spec, and on mobile devices people are more likely to want to default to configs that consume fewer resources rather than configs with higher visual quality. But we’re stuck with it because changing the specified behavior would make existing implementations nonconformant and/or break existing apps if the new behavior is implemented without their being aware of it.

But it’s perfectly fair to ask for clarification and what you’re suggesting sounds like a good start. Could you please open a tracking bug in the Khronos public Bugzilla against project EGL, component API Specification, containing the suggestion?


Bug 327:

Thanks, Tom. Our meeting schedule is slow in August but I’ll make sure this gets on the agenda. At a guess we’ll do a spec update in September with some clarification on this point.