View Full Version : Will Maemo 6 use OpenWF or continue to (just) use Clutter
11-24-2009, 04:50 PM
I'd be interested if anyone is looking at using OpenWF Composition (newly ratified by Khronos.org) in Maemo 6 or beyond?
OpenWF Composition provides some good methods for 2d composition of surfaces without having to rely on OpenGL ES (necessarily).
Of course it all depends on what your applications are doing and whether you have a GPU turned on anyway...(or there is any other hardware present - e.g. an OpenVG accelerator - which could be used for low power composition)
Clutter won't be officially supported in Maemo 6. You should look better in the direction of Qt GraphicsView. See e.g. http://talk.maemo.org/showthread.php?t=34686&highlight=graphicsview&page=4
11-26-2009, 08:27 PM
Thanks for the confirmation on Clutter deprecation.
I've looked at QGraphicsView - it all looks good and makes sense - especially when you look at it from one application's usage - but what I'm struggling with is how the overall 'system' scenegraph will be managed in maemo 6 - i.e. Homescreen/Launcher, Video players, games, java, webkit (itself with DOM with embedded video objects etc) as well as multiple running applications + transitions/animation frameworks...
Is everything rendered in/from QGraphicsView? (and composited using alpha rendered widgets?)
Obviously I know its possible - some good examples of video integration from last year - videos-get-pimped (http://labs.trolltech.com/blogs/2008/11/28/videos-get-pimped/) as well as lots of other graphical goodies in the labs.
However - a single QT-based system scenegraph AFAIK hasn't been used before? Even on Mac and Windows there is an underlying windowing system which Qt renders surfaces/pixmaps to. [though there is QWS on Qt/Embedded - which provides simple windowing services?]
You still have X11 compositing with Maemo 6 around right? But you wouldn't be using it right?
With Maemo 6, with Qt, on hardware accelerated platforms, there is going to be a massive dependency on the quality and interaction between rendering backends and EGL, OpenGL ES drivers, Gstreamer/OpenMAX IL implementations etc - and then you get it all together in a QGraphicsView scenegraph - maybe with animations too and hope its all works and is performant....
or have I got things totally wrong and its all much simpler than that?
I'm coming from a hardware adaption implementation direction - I want everything to take advantage of underlying hardware - be performant in both processing power, bandwidth and memory usage.
...and I'm interested in modelling the system performance for real world UIs with particular applications running too :)
11-30-2009, 01:23 PM
OpenWF is just detail - how you do composition is important - but it doesn't really matter whether you rely on one API or another.
I'm more interested in the question I posted above, about there being one single 'system scenegraph' using QGraphicsView rather than a QT based graphics stack&scenegraph (using QGraphicsView) with other applications/processes doing more traditional 'out-of-band' [my own inaccurate terminology] composition of 2d surfaces [with video, 3d OpenGL ES graphics or whatever].
Changed post title to get some more eyeballs on this question.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.