I have been working with ES lately, and have noticed something a little painful.
I have had to do porting work to OpenGL applications because the ES API is not a subset of OpenGL. Functionality is a subset, but not the API.
This has been causing me – and others – lots of work and effort.
I have also found myself explaining over, and over that ES is a functional subset of opengl, not an API subset , so yes, work and ($) will be required to get this thing to work with ES…
Maybe the fixed data type, and all of the glFooX calls could be included with OpenGL 2.1?
My guess is that OES_fixed_point and OES_compressed_paletted_texture would be a really hard sell to the ARB. Within a generation or two these two extensions aren’t likely to be “relevant” on new devices anyway. I don’t think something short-lived like that is likely to find its way into 2.1. Now, I do understand that the embedded market is different from the desktop market. That’s part of the reason why the Khronos group is a separate organization from the ARB.
However, you may well be able to convince one of the big-name IHVs to add support for those extensions to their driver. That seems way more likely to happen.
