On Mon, 2005-08-15 at 20:06 +0200, Soeren Sandmann wrote: > Havoc Pennington <[EMAIL PROTECTED]> writes: > > > So random thoughts. > > A few more random thoughts: >
All good stuff, Piccolo and Java3D have some ideas here - > - Zooming is more than just setting a transformation matrix because > the reason you want to zoom is to see more details. So somehow a > model needs to be aware of how much detail should be drawn. Piccolo seems to have this, since it's designed for "zoomable user interfaces" > - Collision detection is worth at least thinking about, or you'll end > up with even more O(n^2) algorithms ... IIRC this is a primitive in Java3D and can trigger behaviors. Seems like a good hook to provide. > - Make sure the entire scene isn't redrawn every time something > changes. Also make sure the entire scene isn't *traversed* every > time something changes. Java3D seems to have API designed for this, e.g. a bounding sphere you have to be inside before a behavior will check whether to run, and requiring you to set a "can change aspect xyz" flag for things you want to be able to change on the fly (i.e. everything is "const" by default so Java3D can optimize it). I don't really know what they optimize for const vs. mutable objects, or what the compile() method does, though. > - The ability to have translucent 'windows' with a fixed position on > the screen. This could be tricky to do while having both good-looking and > efficient scrolling. A local compositing manager might be useful for > this. How will this work on Windows? Piccolo docs and examples mentioned a couple different ways to do this, but I didn't read in detail. I got the vague impression they were doing it via a hack. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list