RE: GtkGLExt (was Re: Gtk 3.0)
Well... this seems to turn on a few flames... so let me put some of this to rest. For anyone to say OpenGL is niche, and does not apply to everyday apps, I again remind you of iChat and the OS X Panel. Granted it has only recently found prominence in the desktop but it is quickly making way as OGL hardware acceleration becomes standardize (has been for some time). To look back at the past decade and say look desktops are all 2D, not realizing it has to do with memory and CPU/GPU issues, which are no longer issues is simply wrong. The next decade of desktops, more importantly GUI (Graphical USER -- hello!!! Interfaces) WILL have a blinding array of 3D widgets which will be like eye candy to most users, and as they see it they will want it more and more. I do NOT work at a facility which requires 3D visualization to accomplish its tasks, but users are starting to ask and want. Can I do a walkthrough of our warehouse to see how much material I have?, Can we have a little computerized white box, with a virtualized pallet to do color matching in? This has NOTHING to do with scientific engineering or niche market. It has to do with the future of interface design. I work in a ink manufacturing plant, and by that argument, we should mix it all by hand, since that is how they did it 5000 years ago! 2D is NOT the end of all GUIs. It simply is not! R2 space can not hold as much date/widgets/whatever as R3 even if the axis were infinite! they (users) want 3D buttons that pop, role, jump, and wink at them too. They want there pictures to start bending, bouncing, and getting all organic on them. To say that GTK does NOT need OGL, is to say they sun is not going to rise in the morning. To say that GTKGLext (a great tool to be sure) is good enough, is to slap a hand in the face of all of use who see where this is going. The greatest problem with the linux community (one I myself am having to learn about) is this indelible ego that the data and function has to be correct and nothing else. Sorry if the user can not visually keep up or understand what you present, it won't make a difference how good the app works in the back, it IS the eye candy that gets the user to use it. GtkTreeview in 3D? I can thing of a dozen categorization applications in seconds. FYI - OS X is a FreeBSD engin, with NextStep as its windowing system. It uses OGL IN the windowing system (quartz / composer), and it is the hottest desktop on the market. No one, and I mean no one, has even come close! And lets not forget all the work that is being done on Compiz why? For the masochism of it?!? No! Because that is where the future of desktop are, in 3D space! IMMHO, if Gtk is to keep up, as the cross platform interface it promises to be, it will need OGL to be fully modularized or integrated somehow. I don't even think GtkGLExt is that far, other than the OS X side of it, which with demand will certainly improve. P.S.the comment: Ah. You are such a loser. Go away., has no business on this forum, the point is a good one, and your minimization of it, a poor show of understanding. EMAILING FOR THE GREATER GOOD Join me Date: Sat, 5 Dec 2009 19:48:06 +0100 From: y...@physics.muni.cz To: jose.carlos.pere...@ist.utl.pt Subject: Re: GtkGLExt (was Re: Gtk 3.0) CC: gtk-app-devel-list@gnome.org On Sat, Dec 05, 2009 at 04:22:36PM +, Carlos Pereira wrote: We must atract more scientifc/engineering applications for Linux and GTK, because this is exactly the kind of stuff that enterprises and universities are demanding. If we have fantastic operating systems and desktop environments in the free software world, but most of the scientific/engineering aplications only run in Windows/Mac OS X, people will be forced to use them, even if they would rather prefer to use Linux/BSD... I have many friends in this situation... I'm afraid you explain it from your viewpoint. But looking at your reasoning from the `desktop' viewpoint there are troubles. 1) Objective. There will never ever be a scientific `killer app'. Every little branch of science, or even an individual scientific problem, has specific needs. Hence the applications are inherently scattered and each individual app is used only by a small group of people. Even the `universal' commerical tools such as Matlab are far from being universally used [among scientists]. This makes hard to see sci/eng apps matter *at all*. 2) Subjective. Do your graphs have round corners and include the user's IM status? Can your data acquistion software synchronize the data with an iPod? Are your reports summarized to 140 characters and sent to Twitter? No? Does your app help people with some difficult to understand and much more difficult to solve problems instead of facilitating idle chit-chat while consuming power for visual effects? Ah. You are such a loser. Go away. Regards, Yeti
Re: GtkGLExt (was Re: Gtk 3.0)
Dear Emmanuele, yes. and that, apart from games and scientific/technical applications, it's not at all common. the amount of code using OpenGL is relatively limited (hence niche) compared to the rest of applications in the GNOME stack (or even in the whole Linux ecosystem); it's *usage* is limited, not the size of the codebase. If you go to Amazon and search for OpenGL books, you get this list with 2607 (!!!) results: http://www.amazon.com/s/ref=nb_ss?url=search-alias%3Dstripbooksfield-keywords=openglx=20y=19 Many of these books have been published in the last 5 years, some in 2008 and even 2009. The fact is, the OpenGL community is much larger than our GTK community. If scientific/engineering applications are a niche in the GTK world, that is not a OpenGL weakness, that is a GTK weakness. We must atract more scientifc/engineering applications for Linux and GTK, because this is exactly the kind of stuff that enterprises and universities are demanding. If we have fantastic operating systems and desktop environments in the free software world, but most of the scientific/engineering aplications only run in Windows/Mac OS X, people will be forced to use them, even if they would rather prefer to use Linux/BSD... I have many friends in this situation... Cheers, Carlos ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Sat, Dec 05, 2009 at 04:22:36PM +, Carlos Pereira wrote: We must atract more scientifc/engineering applications for Linux and GTK, because this is exactly the kind of stuff that enterprises and universities are demanding. If we have fantastic operating systems and desktop environments in the free software world, but most of the scientific/engineering aplications only run in Windows/Mac OS X, people will be forced to use them, even if they would rather prefer to use Linux/BSD... I have many friends in this situation... I'm afraid you explain it from your viewpoint. But looking at your reasoning from the `desktop' viewpoint there are troubles. 1) Objective. There will never ever be a scientific `killer app'. Every little branch of science, or even an individual scientific problem, has specific needs. Hence the applications are inherently scattered and each individual app is used only by a small group of people. Even the `universal' commerical tools such as Matlab are far from being universally used [among scientists]. This makes hard to see sci/eng apps matter *at all*. 2) Subjective. Do your graphs have round corners and include the user's IM status? Can your data acquistion software synchronize the data with an iPod? Are your reports summarized to 140 characters and sent to Twitter? No? Does your app help people with some difficult to understand and much more difficult to solve problems instead of facilitating idle chit-chat while consuming power for visual effects? Ah. You are such a loser. Go away. Regards, Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
Thanks Javier, it's good to know that EmmanueleBassi http://live.gnome.org/EmmanueleBassi is now taking care of GtkGLExt integration with GTK... Regards, Carlos Hello Carlos, 2009/12/3 Carlos Pereira jose.carlos.pere...@ist.utl.pt: That's why I asked in the first message of this thread, what are the plans regarding GtkGLExt. To the best of my knowledge, GtkGLExt is still the official way to bridge GTK and OpenGL: http://gtkglext.sourceforge.net/ are there plans to integrate this via Cairo and discard GtkGLExt? that was mentioned in this list years ago... OpenGL integration into GTK+ is part of project Ridley [1]. Here the bug report: [2] The project was recently moved to gnome git too [3] and seems to be quite active. [1] http://live.gnome.org/ProjectRidley [2] https://bugzilla.gnome.org/show_bug.cgi?id=119189 [3] http://mail.gnome.org/archives/gtkglext-list/2009-October/msg5.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
(Sorry, I'm sending this via my phone so it's not going to be nicely formatted; I apologize) I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) cairo should get GPU acceleration for 2D drawing, which is what most of users really care about; 3) if you want a 3D canvas you should be using Clutter. Integrating raw GL inside a gtk+ application is a niche requirement enough that I'm not at all sure it should be moved to gtk+ itself. And if you're dropping into raw GL there is no way you are not a niche use case. On 4 Dec 2009 18:13, Carlos Pereira jose.carlos.pere...@ist.utl.pt wrote: Thanks Javier, it's good to know that EmmanueleBassi http://live.gnome.org/EmmanueleBassi is now taking care of GtkGLExt integration with GTK... Regards, Carlos Hello Carlos, 2009/12/3 Carlos Pereira jose.carlos.pere...@ist.utl.pt: That's w... ___ gtk-app-devel-list mailing list gtk-app-devel-l...@g... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
Hi Emmanuele, I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 1) If you think GtkGlExt should not be integrated with GTK+ that's fine for me. 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and SINGLE_INCLUDES... 4) Scientific/engineering applications often use OpenGL, which is a well established, well documented, industry-standard with a large, vibrant community, as these foruns clearly show: http://www.opengl.org/discussion_boards/ So all I am asking the GTK team is, please find a solution regarding OpenGL support for GTK-3.0... with or without GtkGLExt... Regards, Carlos 2) cairo should get GPU acceleration for 2D drawing, which is what most of users really care about; 3) if you want a 3D canvas you should be using Clutter. Integrating raw GL inside a gtk+ application is a niche requirement enough that I'm not at all sure it should be moved to gtk+ itself. And if you're dropping into raw GL there is no way you are not a niche use case. On 4 Dec 2009 18:13, Carlos Pereira jose.carlos.pere...@ist.utl.pt wrote: Thanks Javier, it's good to know that EmmanueleBassi http://live.gnome.org/EmmanueleBassi is now taking care of GtkGLExt integration with GTK... Regards, Carlos Hello Carlos, 2009/12/3 Carlos Pereira jose.carlos.pere...@ist.utl.pt: That's w... ___ gtk-app-devel-list mailing list gtk-app-devel-l...@g... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote: I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 4) Scientific/engineering applications often use OpenGL, Exactly. I've been using GtkGLExt in a scientific app for years and I'm quite happy with it. Cutter does not cut it if you need to visualize scientific data in 3D. Unfortunately, scientific/engineering apps seems to *be* niche use. Look at how hard SourceForge tries to hide this software category even though it contains 50× more projects than VoIP which is promimently displayed... So I hope something like GtkGLExt will continue to be available, whether it's called GtkGLExt or not and is integrated into Gtk+ or not. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: GtkGLExt (was Re: Gtk 3.0)
I've sort of followed this chain sorry if I am rehashing something that has already been covered. IMHO I agree that GtkGLExt should be directly integrated into GTK. Most modern user interfaces (IE OS X (NextStep)) are integrating 3D directly into the windowing system. If I am not mistaken the panel is pure Open GL in OS X, and for sure the iChat multi session video window is pure OGL with reflection maps (they love to tout that). Their development toolset is chalked full of OpenGL examples, and composer... well I won't even go there. GTKGLext does NOT currently work well on OS X interface (even though there is a patch for it, which still needs to be changed to use the NSOpenGLView instead of the NSView but that is whole other story). Open GL is not only the standard scientific toolset, it is the de facto hardware acceleration tool set. I don't know of ANY video card vendor that DOES NOT have OpenGL support. In fact I can not think of any other hardware accelerated tool sets (OGL has been it since the early 90's) it WILL be the interface choice of the future. 2D desktops will quickly give way to 3D widgetry, as hardware acceleration improves even further. Just look at compiz! I've already got users asking me to make the app look more 3D, and it would be great to have the toolset to do so. Even though all were doing is simple EPR stuff. IE If I could create a 3D warehouse map that was navigable by the user to see where they have room to store a product, or look at a product space for a visual cue to order more. This is an old concept Motorola developed about its factories and training workers virtually. Of course, this is all a wish list, I can't demand of the community to do the work I my self have no time for, but it would be really really really supercalifragilisticexpialidocious-ly great to have a fully working OpenGL implementation in GTK for OS X, and if it is dropped for GTK 3.0, I'm afraid it will not serve the community well. I did not quite catch why it was not a good idea. Saying that is like saying it is not a good idea to have the printing subsystem, or input subsystem be exposed in GTK. GTK in essence is an abstraction layer, to hide the differences in interface functionality, giving the user (programer) a singe interface to write agains. Why should we not have the same thing for OpenGL, which is a component of the user interface? Again this is all MHO, and I certainly have not invested a dime in it, so wether it happens or not I will work around it, but it would be nice, very, very nice, to have an GTKOGLWindow in GTK's base library, or at least something like pango/cairo, as a compiler option module. EMAILING FOR THE GREATER GOOD Join me Date: Fri, 4 Dec 2009 22:26:05 +0100 From: y...@physics.muni.cz To: eba...@gmail.com; jose.carlos.pere...@ist.utl.pt Subject: Re: GtkGLExt (was Re: Gtk 3.0) CC: gtk-app-devel-list@gnome.org On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote: I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 4) Scientific/engineering applications often use OpenGL, Exactly. I've been using GtkGLExt in a scientific app for years and I'm quite happy with it. Cutter does not cut it if you need to visualize scientific data in 3D. Unfortunately, scientific/engineering apps seems to *be* niche use. Look at how hard SourceForge tries to hide this software category even though it contains 50× more projects than VoIP which is promimently displayed... So I hope something like GtkGLExt will continue to be available, whether it's called GtkGLExt or not and is integrated into Gtk+ or not. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, 2009-12-04 at 20:51 +, Carlos Pereira wrote: Hi Emmanuele, I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 1) If you think GtkGlExt should not be integrated with GTK+ that's fine for me. 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and SINGLE_INCLUDES... I guess that you'll have to patch GtkGLExt, and submit patches for integration upstream. 4) Scientific/engineering applications often use OpenGL, which is a well established, well documented, industry-standard with a large, vibrant community, as these foruns clearly show: http://www.opengl.org/discussion_boards/ I never said that raw OperGL is not used, or not useful; I just contend that being able to drop into GL directly is a niche usage - and it's not getting any more mainstream. people flee from OpenGL in disgust, and it's just OpenGL 3.x that's making some progress towards fixing the insane API that it exposes - unfortunately, no GL implementation provides the 3.x API yet. the most people care about, as I said, is being able to accelerate drawing primitives and blending modes and hand them over to the GPU; mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and cairo-drm. So all I am asking the GTK team is, please find a solution regarding OpenGL support for GTK-3.0... with or without GtkGLExt... GtkGLExt is an external project - the GTK+ team has nothing to do with it. even if (and I'm saying *if*) GTK+ provided GL integration for GdkWindows it would basically boil down to two functions: void gdk_window_gl_begin (GdkWindow *window); void gdk_window_gl_end (GdkWindow *window); plus a way to set up the GL context. that's mostly agreed upon, if you read the bug that Javier linked in his email. that's not even close to the API exposed by GtkGLExt. ciao, Emmanuele. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, 2009-12-04 at 22:26 +0100, David Nečas wrote: On Fri, Dec 04, 2009 at 08:51:54PM +, Carlos Pereira wrote: I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 4) Scientific/engineering applications often use OpenGL, Exactly. I've been using GtkGLExt in a scientific app for years and I'm quite happy with it. Cutter does not cut it if you need to visualize scientific data in 3D. clearly, since Clutter is a toolkit aimed at writing User Interfaces. :-) Clutter has a very different scope than raw OpenGL - otherwise we wouldn't even have bothered to write it. it's also one of the non-niche uses of OpenGL, now that the Linux graphics stack is getting more polished and we can actually use OpenGL for writing hardware accelerated user interfaces. ciao, Emmanuele. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
Emmanuele Bassi wrote: On Fri, 2009-12-04 at 20:51 +, Carlos Pereira wrote: Hi Emmanuele, I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 1) If you think GtkGlExt should not be integrated with GTK+ that's fine for me. 2) GtkGlExt is good enough for GTK-2.0, I never had a single problem with GTKGLExt. 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and SINGLE_INCLUDES... I guess that you'll have to patch GtkGLExt, and submit patches for integration upstream. We're interested. We're currently planning what might go into the next GtkGLExt release. We probably need to have a discussion about whether there should be another release targeting Gtk+ 2.x. I'll open this up on the gtkglext-list shortly. 4) Scientific/engineering applications often use OpenGL, which is a well established, well documented, industry-standard with a large, vibrant community, as these foruns clearly show: http://www.opengl.org/discussion_boards/ I never said that raw OperGL is not used, or not useful; I just contend that being able to drop into GL directly is a niche usage - and it's not getting any more mainstream. It is a common requirement for apps that want to do 3D rendering with a cross-platform codebase. Biting off Clutter and its dependency chain is not something developers of such an app are likely to want to incur; and Clutter probably won't provide adequate functionality in a lot of cases. people flee from OpenGL in disgust, and it's just OpenGL 3.x that's making some progress towards fixing the insane API that it exposes - unfortunately, no GL implementation provides the 3.x API yet. For a lot of people using OpenGL (or various engines/wrappers like OpenSceneGraph and OGRE), there's no practical alternative to flee to. the most people care about, as I said, is being able to accelerate drawing primitives and blending modes and hand them over to the GPU; mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and cairo-drm. The volume of code currently using Clutter, cairo-gl, and cairo-drm would be dwarfed by that using OpenGL directly. I think your use of the term niche is a little unusual. even if (and I'm saying *if*) GTK+ provided GL integration for GdkWindows it would basically boil down to two functions: void gdk_window_gl_begin (GdkWindow *window); void gdk_window_gl_end (GdkWindow *window); plus a way to set up the GL context. that's mostly agreed upon, if you read the bug that Javier linked in his email. that's not even close to the API exposed by GtkGLExt. This is certainly a conversation that I'm interested in having. We're certainly aware that there's a good deal of chaff in the GtkGLExt API needs culling. On the other hand, what you're describing isn't *that* far from the parts of GtkGLExt that people actually use. (Well, currently the API has users make_current and then do the begin/end stuff at the GL level.) But I'd like to get us a bit farther along in doing that paring down before discussing this in depth. -- Braden McDaniel e-mail: bra...@endoframe.com http://endoframe.com Jabber: bra...@jabber.org ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, 2009-12-04 at 18:11 -0500, Braden McDaniel wrote: I have the impression that my message is not coming through correctly, because I keep saying the same things. :-) I never said that raw OperGL is not used, or not useful; I just contend that being able to drop into GL directly is a niche usage - and it's not getting any more mainstream. It is a common requirement for apps that want to do 3D rendering with a cross-platform codebase. yes. and that, apart from games and scientific/technical applications, it's not at all common. Biting off Clutter and its dependency chain is not something developers of such an app are likely to want to incur; and Clutter probably won't provide adequate functionality in a lot of cases. which dependency chain? it's the same as gtk+. the most people care about, as I said, is being able to accelerate drawing primitives and blending modes and hand them over to the GPU; mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and cairo-drm. The volume of code currently using Clutter, cairo-gl, and cairo-drm would be dwarfed by that using OpenGL directly. I think your use of the term niche is a little unusual. the amount of code using OpenGL is relatively limited (hence niche) compared to the rest of applications in the GNOME stack (or even in the whole Linux ecosystem); it's *usage* is limited, not the size of the codebase. cairo-drm and cairo-gl are experimental surfaces that have less than 6 months each: it's obvious that the size codebase is limited. Clutter is a new project, compared to OpenGL, and yet *it's* *not* intended to cover the same usage of OpenGL. its intended use covers a canvas for writing applications, not molecule viewers or 3D shooters. that's why GtkGLExt can still be perfectly fine outside of the gtk+ codebase; it provides much more than setting up a GL context, which would be the agreed API for gtk+ to expose, and given the amount of applications actively requiring to drop into GL without any sort of canvas, then it might make sense to keep GtkGLExt exactly as it is. ciao, Emmanuele. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
2009/12/4 Carlos Pereira jose.carlos.pere...@ist.utl.pt: 3) However GtkGlExt is not GTK-3.0 ready, because it cannot be compiled with SEAL_ENABLE and SINGLE_INCLUDES... Bug and patch filled upstream for SINGLE_INCLUDES issue: [1] Also, I've found some interesting threads about this topic here [2] (Sept 2003) and here [3] (Jan 2004). There was a initial RFC here: [4], attached in the bug [5] I posted in the previous mail. Regards. [1] https://bugzilla.gnome.org/show_bug.cgi?id=603829 [2] http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00220.html [3] http://mail.gnome.org/archives/gtk-devel-list/2004-January/msg00169.html [4] http://bugzilla-attachments.gnome.org/attachment.cgi?id=22045 [5] https://bugzilla.gnome.org/show_bug.cgi?id=119189 -- Javier Jardón Cabezas ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On Fri, Dec 4, 2009 at 8:02 PM, Emmanuele Bassi eba...@gmail.com wrote: (Sorry, I'm sending this via my phone so it's not going to be nicely formatted; I apologize) I'm really not working on it - mainly for three reasons: 1) if you want to use GL, GtkGlExt is good enough and integrating it into gtk+ it's not a good idea; 2) cairo should get GPU acceleration for 2D drawing, which is what most of users really care about; 3) if you want a 3D canvas you should be using Clutter. If you want to do ACTUAL 3D rendering your choises are OpenGL and OpenGL, Clutter doesn't come anywhere near it. It's true that the API is getting better in 3.0+ but you can still do the same with 2.0+. Also it's a matter of personal taste. At the dawn of time John Carmack chose OpenGL and urged all GPU vendors to make OpenGL drivers because of the horrible DirectX API. Of course DirectX has come a long way since, but if you want any form of cross-platform support your only choice is still OpenGL. Integrating raw GL inside a gtk+ application is a niche requirement enough that I'm not at all sure it should be moved to gtk+ itself. And if you're dropping into raw GL there is no way you are not a niche use case. It may be niche as in not many apps use it, but that hardly makes it any less important. When companies like Autodesk ports ther many many $$$ apps to Linux they don't have the choice of using GTK+ As far as I can tell GTK+ is the only widget API on any PC platform that doesn't have an OpenGL widget/view. Not being able to use advanced 3D visualizations in modern day apps seems rather odd IMNSHO. Regards Jacob Kolding On 4 Dec 2009 18:13, Carlos Pereira jose.carlos.pere...@ist.utl.pt wrote: Thanks Javier, it's good to know that EmmanueleBassi http://live.gnome.org/EmmanueleBassi is now taking care of GtkGLExt integration with GTK... Regards, Carlos Hello Carlos, 2009/12/3 Carlos Pereira jose.carlos.pere...@ist.utl.pt: That's w... ___ gtk-app-devel-list mailing list gtk-app-devel-l...@g... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGLExt (was Re: Gtk 3.0)
On 12/05/2009 12:28 AM, Emmanuele Bassi wrote: On Fri, 2009-12-04 at 18:11 -0500, Braden McDaniel wrote: I have the impression that my message is not coming through correctly, because I keep saying the same things. :-) I never said that raw OperGL is not used, or not useful; I just contend that being able to drop into GL directly is a niche usage - and it's not getting any more mainstream. It is a common requirement for apps that want to do 3D rendering with a cross-platform codebase. yes. and that, apart from games and scientific/technical applications, it's not at all common. Biting off Clutter and its dependency chain is not something developers of such an app are likely to want to incur; and Clutter probably won't provide adequate functionality in a lot of cases. which dependency chain? it's the same as gtk+. the most people care about, as I said, is being able to accelerate drawing primitives and blending modes and hand them over to the GPU; mostly, for 2D-inside-3D environments -- see Clutter, cairo-gl and cairo-drm. The volume of code currently using Clutter, cairo-gl, and cairo-drm would be dwarfed by that using OpenGL directly. I think your use of the term niche is a little unusual. Agreed. the amount of code using OpenGL is relatively limited Correct - Now ask yourself why. IMO, the causes historically have been and are: - Lack of usable drivers, esp. on Linux. - Demands on CPU-powers (10 years ago, even simple wire-frame graphics were a CPU challenge on Linux). - For most desktop applications 2D is sufficient, even less need advanced 3D. Historically, these reasons were both causes for GUI-toolsets (such as Gnome) to favor other toolset libs on their low levels in favor of other toolset libs. The situation would be entirely different today, if Linux had performant OpenGL drivers and if GUI toolchains would have based their graphics works directly on OpenGL (or any other performant, low level 3D graphics API). Clutter is a new project, compared to OpenGL, and yet *it's* *not* intended to cover the same usage of OpenGL. its intended use covers a canvas for writing applications, not molecule viewers or 3D shooters. Future will tell if this isn't much more than yet another 3D library amongst those many already existing ones ;) that's why GtkGLExt can still be perfectly fine outside of the gtk+ codebase; it provides much more than setting up a GL context, which would be the agreed API for gtk+ to expose, and given the amount of applications actively requiring to drop into GL without any sort of canvas, then it might make sense to keep GtkGLExt exactly as it is. Agreed. Besides fixing bugs and reflecting Gtk API changes to it, I don't see much reasons for changing anything. Ralf ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
