In your message of 11 September 1999 you write:
> Thomas Roell writes:
> > It's still an ugly problem. For an application programmers point of
> > view, I really don't like the idea of GetProcAddress() be dependant
> > upon the context it's called under. It's just a nightmare and a
> > predictable recipe for disaster. On the other hand, letting libGL do
> > the indirection for unknown extensions is very tricky.
>
> And potentially slow?
Exactly. And if you want to use this pointer scheme for core-functions
as well (glVertex3f), then it might be unacceptable.
> My vote would be in favor of a solution that puts the
> burden on the application. It is an limited problem
> to solve: the app needs to maintain some GLEnv per-context
> storage of pointers (as long as we promise that pointers
> stay valid for the entire existence of a context). This
> is generic enough to be put into some portable toolkit,
> isn't it? I mean, the Quake-style dlopen/dlsym table
> could handle this kind of switching easily.
Any of those solutions require structural changes in a program being
ported. This is a big concern for people porting commercial
applications.
- Thomas
--
Thomas Roell /\ An imperfect plan executed violently
Xi Graphics / \/\ _ is far superior to a perfect plan.
[EMAIL PROTECTED] / / \ \
/ Oelch! \ \ George Patton
