Re: OpenGL option for GTK+ (bug #119189)
- From: Naofumi Yasufuku <naofumi yasufuku net>
- To: Tristan Van Berkom <vantr touchtunes com>
- Cc: GTK+ Development List <gtk-devel-list gnome org>, GtkGLExt Development List <gtkglext-develop lists sourceforge net>
- Subject: Re: OpenGL option for GTK+ (bug #119189)
- Date: Fri, 16 Jan 2004 11:46:46 +0900
On 04.1.16 0:50 AM, "Tristan Van Berkom" <vantr touchtunes com> wrote:
> Naofumi Yasufuku wrote:
>> So please help me to realize the purpose of providing well-defined,
>> flexible, multi-platform OpenGL support API for GTK+.
> Hi all,
> I've went back in time and re-read our entire thread back in september
> (OpenGL support in GTK+) and reviewed the RFC provided by the GtkGLExt team.
> The thread in its entirety:
> The RFC:
> Point 3.1 in the RFC above basicly rephrases the options suggested for
> review by Owen here:
> I tend to agree with Sven in his reply here:
> Sven > IMHO, libraries improve by modularizing them. GTK+ has already grown
> Sven > too large and I would welcome if it would be split into smaller pieces
> Sven > instead of more stuff being added. Other people have expressed similar
> Sven > opinions.
Recently, I also tend to agree with Sven.
Tristan > - api/abi changes will be easier to propagate across branches
Tristan > (example: A decission passes that all gtk_signal_* should
Tristan > be changed to g_signal_* calls, developer "A" implements
Tristan > this effortlessly because of his particular knowlage of the
Tristan > signal system and GtkGLExt is also updated accordingly).
Tristan > - one can respond to the question "does gtk have support for
Tristan > graphics acceleration ?" with the simple answer "yes" instead
Tristan > of "well there's some dudes on sourceforge..."
Sven > These two points can be easily achieved by putting the GL library
Sven > GNOME CVS so that everyone who has access to gtk+ may contribute to
Sven > gtk+-gl as well.
I think GtkGLExt's CVS repository should be hosted on GNOME CVS to work in
cooperation with GTK+ hackers.
> and would opt for solution 3 (of point 3.1 in the afore mentioned RFC):
> "add this support into a separate library shipped with gdk/gtk."
I would opt for solution 4 (OpenGL stuff is not shipped with gdk/gtk but
officialy "blessed"). GtkGLExt's GdkGL stuff (libgdkglext library) is not
yet mature enough (e.g. GLXPbuffer support issue, etc.), so I think it
should be developed separately for the time being...
> an OpenGL API is significantly big enough IMO to merit its own library,
> furthermore; it's obvious to the developer whether they should link against
> an OpenGL API or not (IMO, splitting gobject from gtk was a good move,
> GTK+ should be reasonably lightweight depending on what you want
> to do with it, no ?).
> The problem we encounter here though is the following:
> The GdkGL stuff makes sence by itself (an OpenGL drawing kit for gtk
> with dependancies on the native gtk "drawing kit") and it just doesn't
> make sence to me to add the "gtk_widget_set_gl_capability()" APIs into the
> same library (same would apply to a GtkGLDrawingArea).
> While adding theese functions to the actual GtkWidget api
> i.e. GTK_WIDGET_GET_CLASS(widget)->set_gl_capability()
> makes sence semanticly; it is a nightmare in terms of dependancies
> (build or otherwise).
> This would leave us with a bag of orphaned initialization stubs, hmmm
> A.) Would it be acceptable to put theese functions (or this widget)
> in the GdkGL library as an exception (OTOH, is there an advantage
> to having a smaller list of distributed packages) ?
> B.) Would a seemless implementation of theese functions at the
> GtkWidget level be possible (without dependancy issues) ?
> gtk_opengl_init() would effectively check for the
> presence of the GdkGL library and possibly load it as a module.
> Calls to: GTK_WIDGET_GET_CLASS(widget)->set_gl_capability()
> and friends could kindly return errors when the GdkGL library
> is not present or not loaded.
> C.) What about "GtkGL" ? it would contain the
> "gtk_widget_set_gl_capability" api's or a toplevel
> `g_object_new(GTK_TYPE_GL_DRAWING_AREA, NULL);' implementation
> along with some cool derived widgets like GtkGLLabel with antialiasing
> and rotations and whatnot or a "LightWave 3D object viewer"
> widget like the demo that currently comes with the GtkGLExt package
> (and I guess a wealth of funky 3D stuff that would evolve with a
> GtkGL package).
I'm planning to replace "gtk_widget_set_gl_capability()" APIs with
GtkGLDrawingArea widget in GtkGLExt-2.0.
libgdkglext library - GdkGL stuff (GdkGLConfig, GdkGLDrawable,
GdkGLWindow, GdkGLPixmap, GdkGLContext, etc.).
libgtkglext library - OpenGL-capable widget set (GtkGL stuff).
Though most of the time programmers would only need to use GtkGLDrawingArea,
but GdkGL stuff's flexibility is still there.
] [Thread Prev