Hi;
On Thu, 2007-06-14 at 22:00 +0100, Tom Cooksey wrote:
> 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...
>
Ok.
> 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).
>
Ok - btw clutter trunk now mostly supports GL ES, if you have drivers
for your MX31 it could be worth giving it a spin.
> 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.
>
Ok now your worrying me ;-)
> 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.
Ok.
>
> Questions:
>
> 1) What do you think to my proposed architecture? Be brutal, I can take it!
> :-)
I think you are seeing a problem thats not there and think windowing
systems are much less complex / easier to create than they actually are.
In my book if something is old and still heavily used thats a good thing
- it means its mature and proven. X is very extensible you know and its
core originally developed on computers many times *less* powerful than
your MX31 ;)
> 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?
If you really want to write a server why cant you just use clutter as a
dependency for its rendering ? Making it 'just' a server severely limits
is use. What if I want to use clutter as a canvas in my GTK+ application
already running on X (like most people run GTK) ?
> 3) Are there any similar solutions out there which a) use OpenGL ES
> acceleration b) allow graphical items to be defined not drawn?
Not that I know of.
> 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?
Yes exactly. Afaik not many GL ES drivers can actually handle multiple
contexts. Also if you have a server <-> client architecture with the
server doing all the actual rendering (i.e clients indirectly via some
kind of custom ipc proto) then you only need a single context ?
>
> 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.
>
I dont mean to sound really negative here btw :/ The idea of a server
<-> client split is pretty interesting but;
- I dont see why clutter cant still be a lib your server uses for
rendering. This doesn't limit clutters use cases.
- If the UI is very simple (ie mobile phone like) its going to be
a hell of a lot simpler than a full blown windowing system and
thus more likely to succeed. This could actually be pretty cool.
I have thought about this kind of thing before.
- Its a lot of work even in above case and difficult to get right.
Many thanks;
-- Matthew
--
To unsubscribe send a mail to [EMAIL PROTECTED]
