Re: OpenGL option for GTK+ (bug #119189)

[Naofumi Yasufuku <naofumi yasufuku net>]

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:
> http://mail.gnome.org/archives/gtk-devel-list/2003-September/thread.html
> 
> The RFC:
> http://bugzilla.gnome.org/showattachment.cgi?attach_id=22045
> 
[snip] 
> 
>    Point 3.1 in the RFC above basicly rephrases the options suggested for
> review by Owen here:
> http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00254.html
> 
> I tend to agree with Sven in his reply here:
> http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00241.html
> 
> 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 > 
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
into
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) ?
>        <idea>
>               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.
>        </idea>
> 
>    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.

Regards,
--Naofumi