Hello. I did read this nearly two months old discussion. It would be nice to have one scenegraph. Such scenegraph can handle both 3D and 2D. See modern game engines how they handle 3D and 2D renderings.
GTK already has a some sort of scenegraph built-in, because one can trace all widgets starting from the top window. A code was (re)posted recently in gtk lists somewhere. A better scenegraph could be written. (Could openscenegraph, openinventor, coin3d, etc. be used? 3D comes free.) Scenegraph is very easy to use if the user operates on the graph explicitly. Compare Glade and XXL (graph editor) for GUI authoring. With Glade they suggest to predesign the GUI (on paper?). Custom widgets can be built using existing nodes, but more efficient widgets can be hardcoded later. Compare to Csound's instruments (script) and opcodes (C coding of script). This gives means to easily test new widget ideas. Two different zoom modes can be found: one where the whole rendering is scaled and another where individual objects are scaled (fonts in Mozilla). In scenegraph, the first means that the doc's top node is affected, and the second means that individual objects under the doc's top node are affected. Resolution-independent font renderings can be nowadays performed in GPU. david.bellot wrote: >On the other handl, it is very seducing to think about an underlying >canvas for the whole desktop (evas, display pdf, etc...) but that would >mean we must rewrite almost all GTK lower levels. Not very productive at >all. Game engine authors have done the same when they switched to OpenGL or to DirectX. Switch was very productive. From: Damon Chaplin <[EMAIL PROTECTED]> >I think you should take it one step at a time, i.e first get a 2D >zoomable, printable, cairo canvas working, then think about 3D. >Otherwise you'll probably spend the next year just discussing what >features should be in it! Scenegraph is very modular as one may first have a basic set of nodes and then may later expand the set of nodes. I have always kept 3D side easier to implement first. Then 2D is programmed with constraints and/or with special nodes. Openscenegraph etc. have already extensive 3D nodes and some 2D nodes. From: "Gustavo J. A. M. Carneiro" <[EMAIL PROTECTED]> >2. (like Jean Br�©afort says) OpenGL is not printable, and IMHO all >applications should have a print option for any useful data they >produce. (by print I mean either on paper or to PDF file). I'm not exactly sure what you mean by printable. The scenegraph is nice in sense that objects may have different interpretations. How otherwise 3D animators could edit and save their animations? How otherwise a renderer or a editor could output alternatively an image or a line drawing? From: Alexander Larsson <[EMAIL PROTECTED]> >Interestingly, this is pretty much how Microsoft seem to be handling 3D >in Avalon, as can be seen in this blog entry: >http://blogs.msdn.com/greg_schechter/archive/2004/05/22/139744.aspx Not all of scenegraph needs to be rendered with one method. Not every node need to have built-in support for every rendering architecture. The system may modify the scenegraph for managing different architectures. All 2D nodes may be moved out of 3D part if needed. In comparison, GTK now has a fixed "scenegraph" built by the application programmer. So, GTK is quite limited. From: Alexander Larsson <[EMAIL PROTECTED]> >All programs that exist can be programmed on a universal turing machine. >That is interesting, but doesn't mean that people actually develop on >turing machines. OpenGL as an API is clearly targeted towards drawing of >3D scenes, and is not at all what you want when you're writing a >predominantly 2D graphical user interface, whereas Cairo is an ideal API >for this. Popular widget system FLTK was earlier programmed with GL. Then they re-wrote it in X/GTK-way. Blender uses OpenGL for all rendering. That made Blender very easy to port to other systems. I'm not exactly sure if 3D and 2D are all in one scenegraph, but I remember reading such plans recently. In fact, the system which Blender uses (scenegraph plus dependency graph) would be needed in GTK as well. I have already though if I could use Blender as a GUI for my applications. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list