Re: OpenGL support in GTK+
- From: Tristan Van Berkom <vantr touchtunes com>
- To: Sven Neumann <sven gimp org>
- Cc: Jeff Franks <jcf tpg com au>, gtk-devel-list gnome org
- Subject: Re: OpenGL support in GTK+
- Date: Thu, 18 Sep 2003 13:26:43 -0400
Sven Neumann wrote:
> What advantages would such a move have over keeping it as a separate
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
(thus easing the development of gtk based applications that
make use of hardware acceleration).
- 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)
- 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..."
IMHO, the centralization of such related libraries will always increase
the perfection of the end product.
I think the question here is:
- "What is the scope of a multi-platform graphics based user
interface tool kit ?"
- "Does hardware graphics acceleration accessability enter that scope ?"
> Is there anything you can only do when GtkGLExt becomes
> integrated into GTK+?
I personaly am of the opinion that you can do anything at any time.
> Unless that is the case, it does IMO not belong
> into GTK+ since it will be perceived as unnecessary bloat by most
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 ?
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
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 ?).
And on the other hand.... (did I really have two hands ? ;-)
] [Thread Prev