These are good questions. I don't have a firm opinion one
way or another yet, but some comments...
I can see the appeal in code being able to simply #include
<GL/glew.h> and target either desktop OpenGL or ES, I guess
with defines for GLEW_ES_ONLY or GLEW_NO_ES for projects
targeting purely one or the other.
In terms of linking, libGLEW (desktop + optional ES) and a
libGLEWes lighter weight ES-only flavor. I guess that would
mesh reasonably with MX. The default stock-standard GLEW
would be a works-everywhere proposition, unless specifically
built to exclude ES or whatever else.
In fact, I tend to use a subset of GLEW specifically
to minimize the binary size of a whole bunch of programs
that link GLEW statically. This branch exists in the
Sourceforge GLEW git repository as subset. It adds the
burden of having to specify the set of desired extensions
at compile-time. (Which I find workable)
The challenge in this scheme would be to generate glew.h
in a manner that completely and correctly limits the
enums and entry points based on GLEW_ES_ONLY and GLEW_NO_ES.
And maintaining that going forward. I don't think there
is much support in the current perl scripts to cross-check
lists of enums etc against other lists, along with the
complication that a lot of core OpenGL stuff in GLEW is done
via extensions, rather than explicitly for each OpenGL version.
An alternative might be to have a ES wrangler header GL/glesew.h
that gets used either explicitly by direct #inclusion or
implicitly via glew.h when GLEW_ES_ONLY is defined. That
leaves a simpler problem of conditionally compiling glew.h
for GLEW_NO_ES - wrapping the ES-specifics only.
It probably makes sense to do the GLEW_ES_ONLY scenario first -
targeting mobile deployment, and GLEW_NO_ES second as a "nice to
Another way to factor the defines might be:
With the default being GLEW_SUPPORT_OPENGL if neither of the
others specified, and in principle any combination being
supportable. But I think generating separate headers for
each supported combination (and multiplexing via glew.h)
might be better than #ifdefing glew.h like crazy.
In all of this it's ES 2.0 that's of more interest, I'm
neutral about ES 1.0, don't mind much either way.
On 5/25/11 12:53 AM, Shariq Hasnain wrote:
> Hi All,Nigel,
> The plan is that applications would use only a single header "glew.h" for ES and desktop.
> GLEW usage for ES should be as similar to that of desktop GLEW.
> But how the extensions can be exposed, there are few option:
> 1. There could be 2 lib one exposing ONLY desktop and the other ONLY ES core
> and extensions. The memory usage will be minimum and the enum would be filtered
> automatically. But then the applications (which targets both desktop and ES
> and wants to check extensions from both) has to take care that it compiles
> for both for which it might need to use some macro(may be same macro which
> will be used inside GLEW lib).
> 2. Expose all desktop GL and ES extensions and core spec and its corresponding
> function pointers(global variables). But then for embedded system there would
> be many global variables( which will be not be required), unnecessary increasing
> the memory usage.
> 3. Expose all desktop GL and ES extensions and core spec but try to do some
> compile time optimizations(at compile time as we know that desktop extensions
> are not supported by ES and vice-versa) so that memory usage can be decreased.
> But how much it can be done need to be checked.
> For the 2 and 3 case we need to take care of variables coming from both desktop and ES.
> Any suggestion ?
> On 24 May 2011 00:37, Nigel Stewart <nstewart@... <mailto:nstewart@...>> wrote:
> I looked over the changes, changes seem uncontroversial to me.
> My git wizardry is a bit limited, but I'll have a bit of a think
> about the correct way to selectively bring changes into the
> GLEW repository, such as --include vs --no-parent for wget.
> So the idea is for glew.h to expose BOTH desktop GL and
> ES together? And glewInit will detect and load the
> relevant API? The idea is to filter all the enums to
> ensure they're not duplicated? Just wondering.
> Keep up the good work.
> - Nigel
> On 5/23/11 6:03 AM, Shariq Hasnain wrote:
> Hi All, Nigel,
> In continuation of the discussion I had regarding adding ES and EGL support to GLEW,I have done the following things :
> 1 - Added core files of ES and EGL.
> The OpenGL ES version 1.0 and EGL version 1.1 are added in the auto/src folder in the files glew_head_es.h and eglew_head.h respectively.
> The egl header file 'egl.h' for version 1.0 is not present in khronos website(Actually it is there but it contains the egl.h for version 1.3), so this version has not been added.
> The higher versions of ES and EGL are added in core_es and core_egl folders respectively.
> 2- The ES and EGL extensions specs are downloaded and parsed to create the desciptors.
> To create the descriptors files from the extensions files two new scipts are added:
> update_ext_egl.sh and update_ext_es.sh.
> Also the update_registry.sh has been modified to use "--include" option instead of the earlier "--no-parent" options.
> The earlier option was downloading all the extensions recursively from http://www.khronos.org <http://www.khronos.org> <http://www.khronos.org>. even when specified the path
> The source code can be cloned using "git clone /git://git.linaro.org/people/shariqhasnain/glew-es_core.git <http://git.linaro.org/people/shariqhasnain/glew-es_core.git>
> Kindly go through it and provide your feedback.
> My next plan is to generate the header files having ES and EGL support.
> glew.h will have ES related stuff and eglew.h will be generated similar to glxew.h/wglew.h.