> > Have you ran recent Qt demos distributed with Qt? I'd say they look > > pretty cool in my book. > > They would not have impressed me a decade ago, let alone today. Many of > them don't even work on either of my Debian machines.
I have one question regarding OpenGL: maybe it's just me, but isn't core, or "historical" core OpenGL blissfully unaware of simple concepts such as a path, a brush, stroking a path etc? This was long time ago, but I recall that drawing a circle using OpenGL implies that you (or some middleman library) has to discretize the circle into triangles, and then render that. Again, correct me if I'm wrong, but typical OpenGL-based UI rendering will do good old antialiased software 2D rendering on OpenGL textures, and the composite some simple 3D models with those textures applied. [Or it may, at a cost of generating *way more* triangles, use shader programs.] That way you can get goodies like shadows of text rendered in a window with transparent background, but it's really awkward to do directly in OpenGL. These days I imagine this "2D" rendering can be done using shader programs, but that excludes a lot of commonplace hardware outright, and hits some implementation bugs hard (just look around at various game forums). And I really don't quite love the idea of generating a bazillion triangles for the 3D hardware to then shade: I wish 3D hardware could work with splines of some sort (does it?). AFAIK/IIRC, as soon as you wish to move to a higher level scene description, where basic primitives such as paths live in 3D, you have to implement a whole lot on top of OpenGL, and there are no real standards as to how to do it. If anything, Cocoa and MPF (?) may be examples of how to go about it, but that's a long shot of where we'd all like to be. I would like nothing better than to work with hierarchical interactive display representation, where simple things remain simple: say you have a letter shown in your text editor widget, and you want to know where the said letter is located. With a scene description graph, you can extract that information -- the way Qt does it so far either requires the text layouter to provide you with relevant API, or you have to plug yourself between the layouter and the paint engine and literally listen for where the glyphs get painted. The scene description would be easier to use, of course. If the scene description has links into the underlying text document, as it well should, then it gets even easier. So, please understand that I'm not oblivious to benefits of thinking in higher levels of abstraction, but I'm also practical and know that Qt provides me with a whole big lot of cross-platform functionality that simply doesn't exist anywhere else in one coherent platform. Oh, and it's not like scene graphs and whatnot cannot be nicely done in C++ ;) (ducks and runs). Cheers, Kuba _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
