On Wed, 18 Dec 2002, Andreas Beck wrote:
> Rodolphe Ortalo <[EMAIL PROTECTED]> wrote: > > > What about 2 independent applications sharing a single 3D engine? > > :-) - yeah - what about any two apps sharing the same graphics subsystem > (apart from X) ;-). > > > > Which widget library? Some of your own or something more general? > > One of my own. Basically something to do away with an ugly TCL/Tk > script that is used to control eccet. The idea is to have something that > can nicely live side by side with other stuff on a GGI visual. > > Existing libs made that cumbersome to integrate, as I want several > LibGGI native windows that will display rendered 3D-stuff in realtime > and accept mouse and key commands _plus_ one or more control windows > - that may be as slow as they want - to give a GUI for stuff that is > not easily controlled with keyboard and mouse. > > > The reason for eccet itself not using a widget library is speed. I want > highspeed access to the graphics frontend (X). LibGGI provides that nicely > for me. And I don't want to bother with some intermediate layer for a > widget lib like GTK. I have sped up a simple application (planeview) > by around one order of magnitude by just porting it over from GTK. > And to my knowledge the original implementor had already played tricks > to make it fast on GTK. > > I can send you the code if you like. It has some special widgets I happen > to like (e.g. dials like used in xv). Yes! These are exactly my dreams for the (near) future of libggi. What I think is needed is a more evolved concept of a subvisual. The current one can only be used to create a rectangular viewport on an existing visual is unfortunately insufficient. What we need is a subvisual that can be defined by an arbitrary number of clipping regions. Rectangular probably, but it would be pretty sweet if we could get the functionality of the X shape extension (not that I'm very familiar with it). Even more, what is needed is a means for a process to suply this clipping info. Just imagine the results: we'd get all that the dri project has accomplished and more! The XGGI server merely hooks its clipping information to a subvisual on which you can fire up a ggiMesa app, and you get effortless OpenGL with direct rendering (note that I'm not suggesting that this subvisual be used for all X windows as the current implementation for this functionality in X is probably more efficient for the common case). Not only that, but these pieces would be windowing system independed so Fresco (or any other windowing system) would get direct rendering as well. This is what I think is important at the moment. A flexible subvisual along with ggiMesa and XGGI would give us all that XFree86 has with a beautiful design (nearly all actually, Xv would still be missing). Accomplishing this would certainly give the ggi project much more visibility and attract many users and developers. Finally, I have to admit that, as a KGI developer, lot of these ideas are focused on libggi running on top of KGI. On the other hand, lot of the current development effort is focused on generic resource management which really makes sense only on KGI (and fbdev) which leads me to believe that libggi on top of KGI is important in the eyes of ggi developers. -Filip
