[Development] FW: how to improve GraphicsView performance

Andreas Aardal Hanssen andreas at hanssen.name
Tue Aug 21 18:12:16 CEST 2012


2012/8/21 <song.7.liu at nokia.com>

>  Hi,
>
> FYI. Can someone help us here ? thanks very much ;)
>
Thanks,
> Song
>

I think a good start would be to run a profiler like callgrind (search
valgrind + kcachegrind) on the code in a host / x86 environment. The code
posted here doesn't really say anything. That code as it stands isolated
cannot be made to run any faster.

I would look at the items' paint() functions, perhaps event functions like
mousePressEvent or timerEvent or whatever else may be, maybe there's stuff
going on outside of painting that's causing things to run slow. My bet is
the number of items multiplied by the complexity of paint() is what's
killing your performance.

Callgrind (above) will give you the x86 instruction count. With relatively
low processor speeds, and using software rendering, it's useful to do some
math. 300MHz means there's 300 million (arm/ppc) cycles per second at your
disposal, let's assume your GUI is allowed to use a fair share of that.
Let's say you have a 800x480 display running at 32 bits. That's 384000
pixels to be updated if you're doing a full screen repaint. If you're
expecting 20 frames per second for animations, for example, you have 39
cycles per pixel. That's quite a lot so you should have enough slack to
render OK graphics on full screen.

If you halve the resolution, you'll have 78 cycles per pixel. If you update
only half the screen at a time, you also have 78 cycles per pixel.

For a 300MHz device, a steady 20fps should be achievable. If you want to go
60Hz, diving the above by three. Now you have 13 cycles per pixel. That's
stretching it. But if your gui only moves small items around one at a time,
or only updates small buttons when pressed, you should be fine.

If you're running some esotheric color depth like 18bit packed (666), you
should stick to the most basic graphics and keep text, curves/complex
paths/polygons to an absolute minimum.

I don't think toggling any options in QGraphicsView is going to do you much
good, altough disabling indexing like you did already is probably a good
idea. Again, if you run a profiler you'll see how much a difference it
makes.

-- 
Andreas Aardal Hanssen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120821/9a8d39c3/attachment.html>


More information about the Development mailing list