On Thu, 14 Oct 1999, John M. Zulauf wrote:
> > a) context-dependent glGetProcAddress (can we handle remote GLX with
> this?)
>
> What happens when one moves a window from a display
> that supports an extension to one that doesn't? (actually I have no idea how
> one does this in Win at all even without extensions) Does the app have to
> scrap all their pointers and start again?
Well, theoretically - yes.
But can you even do this in a multi-headed X setup? You certainly
can't on (for example) SGI ONYX machines...even when all the heads
are identical. Whichever graphics card the window was created
on is where it stays. (Although on an SGI box, you can have
multiple displays hung off a single graphics head - that doesn't
count because X doesn't even know you did that - the displays
end up being simply different views of the same X-managed-area).
I don't see that as a practical problem.
> What about utility libraries that
> have stored the pointers in their initialization (for a given context)? What
> happens when you make a proc call in the wrong context? Do we validate the
> context?
Writing black-box libraries using OpenGL is a bitch anyway - getting
state changes right without the library doing state management for
the entire program (eg Performer, Inventor) is *hard*.
> > b) context-independent glXGetProcAddress
>
> Given that (d) is politically no viable right now this makes the most sense.
> What's odd is that noone has talked about a basic implication of this
> choice. Effectively getProc must **always** return a non-null wrapper (i.e.
> the dispatch table function)... because we do not know if some FUTURE
> context we create will support the ext. Right?
No - surely the driver will know what set of extension symbols
exists within it. It's not like the user can plug in a new graphics
card on-the-fly in the middle of a program run.
If you ask for glBlarfEXT and neither of the drivers that are currently
running are for a card with a functional Blarfatron, then you can expect
a NULL. I'm presuming that the libGL knows what the full set of possible
drivers are up-front without the need to actually open rendering
contexts and such...maybe that's not the case?
Steve Baker (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc. (817)619-2466 (Fax)
Work: [EMAIL PROTECTED] http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1
