GLEW interface when GL is dynamically loaded

[tom fogal-3]

Okay, I've (finally) gotten back to this.  My local tree is dynamically
loading OpenGL through glX or through OSMesa ("OffScreen Mesa"),
depending on user input.  All OpenGL functions, even 1.1 functionality
and glX, are dynamic symbols, generated from files in auto/core/
instead of hardcoded in auto/src header files.  This means that GLEW
does not have a compile-time dependency on OpenGL / glX / OSMesa.

I could conceivably post the patches soon, but they need some work in
terms of presentation.

This creates a bit of a chicken-and-egg problem though, in that I've
broken the old/existing interface.  The previous interface:

  1. Client sets up OpenGL context
  2. Client calls glewInit()

now, though, since one needs windowing system (e.g. glX, wgl) functions
to perform (1), and those windowing system functions are runtime-loaded
by GLEW instead of fixed at compile time, the user must initialize
GLEW first.  Of course, since there's no current context during that
initialization, extension loading will fail.

So I guess a two-stage init is in order:

  1. Client calls glewWinsysInit (or whatever)
  2. Client sets up OpenGL context
  3. Client calls glewInit

Acceptable?

-tom

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

Tom,

> This means that GLEW
> does not have a compile-time dependency on OpenGL / glX / OSMesa.

Just to nit-pick - you mean a link-time dependency, right?

> So I guess a two-stage init is in order:
>
>   1. Client calls glewWinsysInit (or whatever)
>   2. Client sets up OpenGL context
>   3. Client calls glewInit
>
> Acceptable?

The first concern that comes to my mind is binary compatability:

Can step 1 be optional, so existing apps don't need to be rebuilt?

Will it be OK for existing apps linked to GLEW/GL to bypass GLEW
for the GL 1.x entries?

- Nigel


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[tom fogal-3]

Nigel Stewart <nstewart@...> writes:
> Tom,
>
> > This means that GLEW
> > does not have a compile-time dependency on OpenGL / glX / OSMesa.
>
> Just to nit-pick - you mean a link-time dependency, right?

Correct.

> > So I guess a two-stage init is in order:
> >
> >   1. Client calls glewWinsysInit (or whatever)
> >   2. Client sets up OpenGL context
> >   3. Client calls glewInit
> >
> > Acceptable?
>
> The first concern that comes to my mind is binary compatability:
>
> Can step 1 be optional, so existing apps don't need to be rebuilt?

Yeah, that's why I asked, because it does break compat and I can see no
(good) workaround.

We *could* assume that, say, /usr/lib/libGL.so exists on Linux, and
load that.  There's a similar path which seems pretty standard on Mac.
I'm not sure about windows, but I would hope OpenGL is installed to a
standard location.  We could then add an __attribute__((constructor))
function (again, not sure about windows but there must be an
equivalent) which assumes the user wants the 'system' GL and loads
at least the context initialization functions.  Users that want the
non-system GL should/must know to use the alternate entry point
(glewInitLibrary) *before* establishing their context (so that it can
overwrite the [now incorrect] function pointers).

I haven't verified the above works, but it seems plausible.

Another solution is to update docs: clients are told that context
initialization must happen in a file which does not include GLEW.  Then
the defines won't be hit, and the application will use their normal
context init routines (glXCreateContext, etc.).
We could maybe even remove the glX/wgl(/agl?) functions that GLEW
provides, to hammer this home.

> Will it be OK for existing apps linked to GLEW/GL to bypass GLEW for
> the GL 1.x entries?

Well, of course, any file which doesn't include glew.h won't hit the
defines and can thus bypass GLEW that way.

I think you mean `will 1.x functionality still work through GLEW even
w/o a new init stage'.  Unfortunately no.  I had to make *all* GL
calls function pointers initialized by glewInit, because otherwise
one could call /usr/lib/libGL.so's glTexImage2D (for example) after
initializing /some/path's/libOSMesa.so.  Of course, this segfaults (if
you're lucky).


There's really a chicken-and-egg problem here.  1) We want to provide
context initialization functions, so clients can simply include glew.h
(and nothing else) and create their context.  2) Yet GLEW simply can't
know where to get those context initialization functions from until
the user tells us.  If we default to the system GL, then we're back to
square one: clients cannot create an offscreen mesa context.  If we
don't default to *something*, then clients will crash while creating a
context.

I floated the 2-stage init idea as a way to tell GLEW where to load
the GL functions from, getting around (2).  Feedback on alternate
interfaces is certainly welcome...

-tom

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders