Re: OpenGL support in GTK+

[Sven Neumann <sven gimp org>]

Hi,

Tristan Van Berkom <vantr touchtunes com> writes:

> I cant think of many advantages besides any advantages that
> result in the centralization of gtk libraries, theese would be some:
> 
> - the docs will all be in the same place with the same format

You can have this easily. Just use gtk-doc to document your library
and the docs will end up side-by-side with the GTK+ documentation,
perfectly cross-linked and in the same style.

> - group discussion on gtk libraries will take place in the same forum
>   resulting in clarity for all developers working on gtk api's
>   (thus easing the development of gtk+ and GtkGL itself/themselves)

Is there such so much overlap? I doubt there is and if there is, then
this is just a matter or merging mailing-lists.

> - api/abi changes will be easier to propagate across branches
>   (example: A decission passes that all gtk_signal_* should
>    be changed to g_signal_* calls, developer "A" implements
>    this effortlessly because of his particular knowlage of the
>    signal system and GtkGLExt is also updated accordingly).
> 
> - one can respond to the question "does gtk have support for
>   graphics acceleration ?" with the simple answer "yes" instead
>   of "well there's some dudes on sourceforge..."

These two points can be easily achieved by putting the GL library into
GNOME CVS so that everyone who has access to gtk+ may contribute to
gtk+-gl as well.
 
> IMHO, the centralization of such related libraries will always increase
> the perfection of the end product.

IMHO, libraries improve by modularizing them. GTK+ has already grown
too large and I would welcome if it would be split into smaller pieces
instead of more stuff being added. Other people have expressed similar
opinions.

> I think the question here is:
> - "What is the scope of a multi-platform graphics based user
> interface tool kit ?"
> and
> - "Does hardware graphics acceleration accessability enter that scope ?"

First of all, unless I am completely mistaken, we are not talking about
hardware graphics acceleration here. We are talking about adding a way
to use OpenGL 3D API from GTK+. On some platforms the 3D functions may
be hardware accelerated but this is completely out of our scope here.

3D support is not something a lot of applications need. The scope of
GTK+ should be to provide a framework for applications to build
on. This means that it should offer a couple of widely useful widgets
and the framework to extend this set.

If you argue that GL support belongs into GTK+, you can also argue
that there should be a HTML renderer, an application server, a
database as well as video and audio support. But all these things
exist and they integrate nicely with GTK+, although they are not part
of the toolkit.

> unnecessary bloat for a linux distribution to include ? or unnecessary
> bloat for an application to have to link against ? or unnecessary
> bloat to maintained in the same package ?

The latter is indeed an important point. The more code lives in GTK+,
the more bugs are there and the more work has to be put into
maintainance.

What I really meant here is for example unnecessary bloat for people
trying to use GTK+ on embedded devices. Due to the size of GTK2, a
couple of projects decided against porting their software to the GTK2
platform. If we could manage to split GTK+ into a number of smaller
packages or at least allow to configure what widgets to include, GTK+
would become a lot more interesting for the rather large area of
software development on embedded devices.

> On one hand; OpenGL is a standard which already has a few
> implementations so by consiquence it should be relatively easy to
> port from one system to another provided that the implementation
> already exists for that platform, and even if there isnt, (excuse me
> I'm a little rusty, its been a while since I read that code) there
> is a software fallback already implemented in the glx libraries
> (thats what I forget...  was it the "dri" branch that has the
> software fallback operations ?).

You are raising another point here. OpenGL (especially with hardware
acceleration) has always been a nightmare to install. People are
already having a hard time with all the dependencies that have been
added lately. I'm sure that a dependency on some OpenGL implementation
would not improve this situation.

Please don't get me wrong. I believe that it should be easy to
integrate 3D into your GTK+ application and I would welcome if there
was an officially supported GTK+ GL widget library, but I don't think
that it should be part of GTK+ itself.


Sven