On 5/15/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > On Sunday 15 May 2005 18:27, Jon Smirl wrote: > > On 5/15/05, Adam Jackson <[EMAIL PROTECTED]> wrote: > > > On Saturday 14 May 2005 10:45, Jon Smirl wrote: > > > > Our egl extension is supposed to expose the full OpenGL > > > > implementation, right? For example egl Context is not exposing the > > > > full OpenGL context. Don't we need some way to turn on full OpenGL > > > > support and then add all of the defines needed? > > > > > > I don't see why we would need that. The state machine nature of GL > > > should mean that if you only modify a subset of the state then you don't > > > have to worry about the bits you don't change. > > > > > > It may be useful to export an EGL extension to indicate that the GL > > > underneath it is full OpenGL and not the embedded subset, but that > > > extension shouldn't need any new entrypoints I don't think. > > > > How go you create a context with options that are supported in full GL > > from our EGL implementation? There are a bunch of context creation > > options that aren't in EGL. > > Aren't these options basically limited to things you can specify in an > XVisualInfo or GLXFBConfig list but not in an EGLConfig list? That's not a > large list.
Auxiliary and Accumulator buffers for example. We need to check all of the GLX config options and make sure EGL isn't making something important inaccessible. -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93&alloc_id281&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
