I've downloaded clutter and played around with some of the demos etc. It is very nice, but I think it could be so much more. I've been scratching around for ages trying to find a technology to create a complete mobile phone UI with. There's _lots_ of options, but all of them just take desktop technology and apply it on embedded devices. For me, this is not a solution, it's a bodge. I like the direction clutter is taking towards OpenGL ES, but are you sure implementing clutter as a library is the best way to go? I don't mean to criticise... I think clutter's great! I think it's probably best to explain what I want...
I have a Freescale i.MX31 development board (an iMX31 LITEKIT) which I'm intending to develop my phone UI on. It's a pretty beefy processor for an ARM and includes a PowerVR MBX lite 3D accelerator, supporting OpenGL ES 1.1. Apart from that, its graphics processing is pretty dire (It doesn't even have a hardware blitter). I want to use the 3D accelerator built into the processor for the complete user interface, not just games! (Which seems to be the only thing manufacturers can think to use a 3D accelerator for!!). The fact that you want to write OpenGL ES code for clutter is what attracted me to it in the first place (I think it was a post on the OpenMoko or SVHMPC list). Anyway, my UI will comprise of multiple processes, all wanting to draw something on the screen. The two architectures I have found which handle the arbitration are server-based (i.e. X) or use peer-cooperation (i.e. Qtopia and DirectFB). The only server based architecture I can find is X. I don't want X. IMO, it's old and out of date. I don't really want ANY windowing system at all, there's really no need for them with OpenGL / OpenGL ES. So, my proposed architecture has a server process. Clients connect to the server and create graphical items (actors I guess in clutter-speak). Clients don't draw graphical items, they simply define them, assign a unique ID and hand them to the server which may draw and re-draw them as and when it feels like it. Clients may issue operations on items it has created like move, shrink/grow, flip, rotate etc. Taking clutter's ideas, I guess animation timelines could be defined by the client for items too. Clutter is the closest I've seen to this kind of architecture in the sense that it doesn't require X and allows applications to define graphics rather than draw them. Both QT and GTK+ (now they've moved to cario as a back end anyway) use a backing buffer. Yet, if I want to implement my own widgets I have to do so by overriding the "OnPaint" handler! If you compare web user interfaces with native interfaces, the difference in quality is staggering. Technically, one of the big differences I can see which contributes to this is that web UIs are defined where as native UIs are drawn (unless standard desktop widgets are enough in which case you can use glade). XUL is close to what I want but sits a bit too high in the stack for me. XGL is also close, but is still an X server. Questions: 1) What do you think to my proposed architecture? Be brutal, I can take it! :-) 2) If I were to use clutter, is it better to write the server separately and use clutter as a library, or would you be interested in expanding clutter into a server application? 3) Are there any similar solutions out there which a) use OpenGL ES acceleration b) allow graphical items to be defined not drawn? 4) How are multiple processes handled by clutter? From what I can tell from the code, clutter just creates a new drawing context for each process and lets GLX handle things? I realise OpenGL is not a fix-everything, accelerate everything silver bullet, but even if it was just used to image compositing it would provide much better performance. Plus, if OpenGL ES was used for compositing, EGL is implied. Which means OpenVG could be used to accelerate drawing into textures which could then be manipulated with OpenGL ES. Cheers, Tom PS: Sorry for rambling on! It's just that I've been researching this for months and have got a little frustrated. :-) -- To unsubscribe send a mail to [EMAIL PROTECTED]
