On Wednesday 18 July 2012 07:26:55 gunnar.sle...@nokia.com wrote: > On Jul 17, 2012, at 9:17 PM, ext Andreas Aardal Hanssen wrote: > > 2012/7/17 <marius.storm-ol...@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.. >
In my experience your statement is not true. With llvmpipe I could run some ~400x300 pixel QML2 demos(*) at 60 FPS on a 2.4 GHz Core 2 CPU with maybe 40% load. I have also seen a ~480x320 pixel QML1 UI I worked on run at 20 FPS on a 300 MHz ARM9 CPU. The desktop CPU is at least 15x faster. The ratio of instructions per pixel and frame is then, approximately: 15 * 0.4 * (480 * 320 * 20) / (400 * 300 * 60) = 2.56 which is very good for the hard task llvmpipe is accomplisihing, but nevertheless it is slower. (*) with surprisingly little frame rate and CPU load difference between the simplest Pong demo and some advanced ones using pixel shaders - I made sure that I was really using the software renderer, and I was, because the CPU load went to <10% after switching to hardware OpenGL. Cheers, Andreas _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
