[Development] Suggestion on QML portability

gunnar.sletta at nokia.com gunnar.sletta at nokia.com
Wed Jul 18 09:26:55 CEST 2012


On Jul 17, 2012, at 9:17 PM, ext Andreas Aardal Hanssen wrote:

> 2012/7/17 <marius.storm-olsen at nokia.com>
> > (2D accelerators are often bundled with GPUs and perform 2D rendering
> > ops faster than GPUs, but are unusable with QML 2 / SceneGraph; see
> > pvr2d).
> 2D accelerators bundled with GPUs perform 2D rendering ops faster than
> GPUs? Uhmm... that sentence is conflicting in my head, unless you mean
> that you are using highly specialized boards with multiple GPUs (n*PVR)
> on them to do things really really fast in parallel.
> 
> [OT]
> 
> No, I really mean dedicated 2D hardware chips outperform GPUs by far. It's easy to do certain common simple 2D graphics faster than most embedded GPUs I know of, even using the CPU. GPUs are built for (1) 3D transformations on textures, (2) vertex-heavy objects and (3) per-pixel shading operations. But it's easily beat for simple 2D operations like blit (e.g., DMA), filtering/scaling (e.g., FPGAs). Most mobiles / tablet UIs are 90% 2D.
> 
> My point is simply that Qt 5 is best served with a painting backend for QML 2 that can support non-OpenGL technologies.
> 

Though true that 2D blitters support the basic features needed by many UI's it also comes with a lot of limitations. 

They often operate on contiguous memory blocks, which need to be allocated by the kernel and comes which is limited in terms of what you can allocate. On several chips I've worked on, this is a system-wide pool, specified at boot-time.

They would also not support basic primitives, such as drawing rounded rectangles, antialiasing, free rotation, perspective transformation and 9-patch border images. So all of these would have to be rendered in software. This means a heavy mixing of CPU and accelerated drawing and we both know that combination does indeed suck. OpenGL is flexible enough to support what we need while at the same time providing us with very good performance, so it is the best thing we got.

If you know you are not using any of these features, then you could write your own renderer using the scene graph adaptation layer. A renderer that only looks at translate and scale transforms, maybe supports opacity and draws solid color boxes and pre-generated images. Text could be done using the adaptation for glyph nodes to render text using QPainter and then that could also be blitted in the renderer. This is doable today, but it would not support the full QML feature set, so it is not something we will invest time in.

There is also the possibility of using a software emulation library for the OpenGL stack to do all the rasterization in software, if there is no OpenGL chip. QML2 on llvmpipe beats QML1 on QPainter/raster, after all..

cheers,
Gunnar

> -- 
> Andreas Aardal Hanssen
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




More information about the Development mailing list