Hi; On Thu, 2007-06-07 at 16:36 +0200, Florent THIERY wrote: > > I have a few questions regarding clutter, which seems very promising. > This is in regard to the OpenMoko project. I looked into the API > reference manual, but i can't seem to find answears for the following > interrogations : > > * what's the Opengl ES support status ?
It pretty much completely supported now in trunk (not release as yet), though it hasn't been heavily tested so Id consider it experimental at least atm. > * how does interpolated movements work: linear speed/acceleration, > "physics-based" animation ? See Behaviours, Alphas and Timelines for animation handling. There is currently no support for more physics based animations - I've wanted to play with akamaru; http://people.freedesktop.org/~krh/akamaru.git/ and clutter for this kind of thing. > * i am considering starting a zooming list-based UI using clutter; > these lists shall be the visualization of results for local database > queries (abstracted using the Dojo MVC framework). List items could be > pure clutter (containing text/images), or could be embedded GTK+ > widgets; if every list item is a GTK+ object, what's the performance > effect ? Any advice is welcome You cant yet embed GTK+ widgets, though in theory it would be possible with a GTK patched with the offscreen patches. Would also likely take some juggling with events. I've no idea how well it would perform. Performance would basically depend on your underlying hardware. > * can one zoom and move within a bigger-than-the-real-screen GTK+ > widget ? Example: very big image, zoomed webbrowser. The ideal case > would be browsing the web using the webkit GDK port, with fluid > zooming Clutter can scale actors as fast as the underlying GL hardware can scale. > * what about 3D features ? Its best to describe clutter as a mainly 2D canvas but with 3D effects. I wouldn't advise hacking something like Quake in clutter - its aiming at UI's like MCE, front row, coverflow, iphone even, which are mainly 2D but have 3D effects - i.e rotation of elements about x, y axis, perspective transforms, 'simple' use of 3D space. Clutter isn't trying to be a general interface to GL - its trying to give a simple API for doing applications like the above without needing to know hardcore GL - in doing this you do lose some flexibility of raw GL. But if clutter does not give you enough you can drop into regular GL for rendering a custom actor or some such however. > > It seems the openmoko guys are having inherent trouble using GTK+, and > the next hardware rev will get an OpenGL ES enabled chip. In your > opinion, will GTK+ drawing inside clutter allow reducing/supressing > the resource bottleneck ? I have no idea - ultimately it would depend on how fast the GL ES implementation was and if the GTK offscreen rendering could be accelerated. The first step would be knowing what the hardware can actually do. Hope that helps; -- Matthew -- To unsubscribe send a mail to [EMAIL PROTECTED]
