On Mon, 2010-01-11 at 17:50 -0500, Arc Riley wrote: > On Mon, Jan 11, 2010 at 4:30 PM, Braden McDaniel > <[email protected]> wrote: > The glext stuff is getting the axe because GTK+ applications > don't have any special needs in this department (i.e., ones > that aren't shared by non-GTK+ cross-platform apps). IMO, if > there is a convincing argument to be made here, it's one that > refutes that claim. > > Then why not remove context support? GLEW provides glewContextInit > and related functionality. There's nothing GTK+ specific about a GL > context.
You might not want to give us ideas. ;-) As it stands, the GdkGLContext notion is coupled pretty strongly to that of the GdkGLDrawable. It is conceivable (to me, at least) that some future alternative approach to all this might bury the context from direct view. But I don't anticipate anything like this happening in the 2.0 timeframe; and any such change would almost certainly be accompanied by a deprecation period for the old API. > GLEW also provides extension testing, so there's no need to implement > gdk_gl_query_gl_extension beyond mapping it in the header as an alias > to glewIsSupported. Since any app using gtkglext 2.0 would need to > use GLEW, why not make GLEW a dependency of gtkglext and trim the API > down to *only* the explicit functions needed to use GL inside GDK/GTK. I'm pretty sure this function is on our chopping block, too. > Then you could provide gdkglglext.h backward compatibility just > linking gdk_gl_* to the GLEW equiv and list these in the docs as > depreciated, included only to support gtkglext 1.0 apps and recommend > using GLEW directly instead. We're not interested in having GtkGLExt depend on GLEW--especially not just to provide legacy functionality. Users who need what GLEW provides can go directly to GLEW (or GLee, etc.). The next GtkGLExt release is going to require a very recent GTK+, too. It's not going to be a drop-in replacement for GtkGLExt 1.x. It is targeted at new apps and those that are being upgraded to use modern APIs. For better or for worse, we're not really able to avoid breaking API compatibility with the next release (bug 604333). We're taking this opportunity to do some additional culling of bits that represent functionality outside the core role we see GtkGLExt taking. -- Braden McDaniel <[email protected]> _______________________________________________ gtkglext-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkglext-list
