Bug 5447 - (Harri) QPainter drawPixmap( QRect, QPixmap) is really slow.
(Harri)
: QPainter drawPixmap( QRect, QPixmap) is really slow.
Status: RESOLVED INVALID
Product: Qt
General
: 4.6-Fremantle
: N900 Maemo
: Medium normal with 1 vote (vote)
: ---
Assigned To: Harald Fernengel
: general-bugs
:
: performance
:
:
  Show dependency tree
 
Reported: 2009-10-14 20:13 UTC by Harri Smått
Modified: 2010-10-15 12:39 UTC (History)
4 users (show)

See Also:


Attachments
Example program for testing QPainter. (1.01 KB, application/zip)
2009-10-14 21:53 UTC, Harri Smått
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Harri Smått (reporter) 2009-10-14 20:13:40 UTC
SOFTWARE VERSION:
Maemo 5 (Fremantle), Qt installed from Maemo repository.

STEPS TO REPRODUCE THE PROBLEM:
Create a QGraphicsItem based class which draws an QPixmap in its paint method.
Pixmap is scaled using drawPixmap(QRect, QPixmap) method and optionally rotated
by graphics item's transform matrix.

EXPECTED OUTCOME:
Drawing should be rather fast as only basic transformations are used.

ACTUAL OUTCOME:
Drawing image is extremely slow as soon as pixmap is scaled and/or rotated -
much slower than in Maemo 4.

REPRODUCIBILITY:
Always.

EXTRA SOFTWARE INSTALLED:
None.

OTHER COMMENTS:
Since drawing Pixmap without transformations, drawPixmap(QPoint, QPixmap), is
really fast and following code makes drawing much faster;

QRect r( QGraphicsItem's rect );
// This is really slow.
painter->drawPixmap( r, pixmap);
// This is much faster but kinda stupid approach.
QPixmap tmp = pixmap.scaled( r.size() );
painter->drawPixmap( r.topLeft(), tmp );

I suspect that there is big delay in accessing pixmap data from painter. Also
latter doesn't help if you are using transformation matrix.
Comment 1 Harri Smått (reporter) 2009-10-14 20:19:06 UTC
In addition this happens with QImage also, so drawImage is not an easy work
around.
Comment 2 Antonio Aloisio 2009-10-14 21:27:15 UTC
Hi Harry,
thanks for your report.. btw performance issues are not critical nor major
issues.
We'll take a look.
Comment 3 Harri Smått (reporter) 2009-10-14 21:53:54 UTC
Created an attachment (id=1426) [details]
Example program for testing QPainter.

Simple application where user can drag a rotated 200x200 image around the
screen. Image is scaled down from 600x600 in paint method, and QGraphicsItem is
rotated 30 degrees to demonstrate the speed issue mentioned in this bug report.
Comment 4 Eero Tamminen nokia 2010-03-23 17:08:42 UTC
Could you install Oprofile:
  http://wiki.maemo.org/Documentation/devtools/maemo5/oprofile

And check where most of the CPU is spent (in which process and library) /
provide Oprofile profile report so that this can be assigned to correct
component?

(Most likely this will be looked in Harmattan.)
Comment 5 Tarantism 2010-03-29 22:45:08 UTC
Like to add that I've experienced this bug with very slow drawPixmap( QRect,
QPixmap) on an N900.

Confirmed that the extent of QRect matched the extent of QPixmap exactly.
A full screen pixmap drawn with drawPixmap( QPoint, QPixmap ) executes in
~180us whereas smaller pixmaps drawn with drawPixmap( QRect, QPixmap ) take
order 6-7ms.

Workaround, of course, is to use drawPixmap( QPoint, QPixmap ) but I do think
the bug is serious as many developers will not realise that this is the reason
that their apps are going so slow!
Comment 6 alain F 2010-09-16 10:25:19 UTC
within codeBlock, debug mode, insert printf("\n") into the beginning of paint
event make drawPixmap very fast!!!!! hélas there can't be no terminal for
release mode. This may be a cue for the diagnosis of this very annoying bug.
Comment 7 Eero Tamminen nokia 2010-09-16 10:33:00 UTC
Does this apply to all Qt backends you can select from the command line
(native, raster etc)?
Comment 8 alain F 2010-09-16 10:54:51 UTC
dont know. I first programmed a big app (music editor) and find the drawPixmap
very slow. I then isolate the problem and wrote a minimum api wich drawPixmap
inside a paint event of a scroll widget and the printf("\n") was still
necessary (forgive my english !) to obtain a decent speed. I tried to flush
pending event but it was to no avail. I suspect a thread problem. Maybe printf
on a terminal while in paint event implied a switch task beneficial to paint
event though i dont know how (I'm not a qt expert). When i google the problem,
I found very complicated context and very complicated tried solution, but the
problem seem much more basic.
Comment 9 Antonio Aloisio 2010-09-16 11:21:20 UTC
(In reply to comment #8)
> dont know. I first programmed a big app (music editor) and find the drawPixmap
> very slow. I then isolate the problem and wrote a minimum api wich drawPixmap
> inside a paint event of a scroll widget and the printf("\n") was still
> necessary (forgive my english !) to obtain a decent speed. I tried to flush
> pending event but it was to no avail. I suspect a thread problem. Maybe printf
> on a terminal while in paint event implied a switch task beneficial to paint
> event though i dont know how (I'm not a qt expert). When i google the problem,
> I found very complicated context and very complicated tried solution, but the
> problem seem much more basic. 
>
Comment 10 Harald Fernengel nokia 2010-09-16 12:17:55 UTC
Please try running the app with

-graphicssystem native
-graphicssystem opengl

and provide information whether you see a speed-up.

Please also know that Qt 4.6 is closed now, the next version will be 4.7. Can
you test your app with the qt4-experimental (Qt 4.7) packages and see whether
the slow-down is gone?

Thanks,
Harald
Comment 11 Andre Klapper maemo.org 2010-10-14 14:48:17 UTC
Qt bug reports are now handled and centralized at
    http://bugreports.qt.nokia.com/

Qt reports are not handled in bugs.maemo.org anymore.

We kindly ask you to copy this report / file a new ticket in
bugreports.qt.nokia.com if the problem described in this report is still valid
in the latest version. Thanks!
Comment 12 Eero Tamminen nokia 2010-10-14 16:20:35 UTC
(In reply to comment #11)
> Qt bug reports are now handled and centralized at
>     http://bugreports.qt.nokia.com/
> 
> Qt reports are not handled in bugs.maemo.org anymore.
> 
> We kindly ask you to copy this report / file a new ticket in
> bugreports.qt.nokia.com if the problem described in this report is still valid
> in the latest version. Thanks!

Does that tell in which Maemo version the Qt bug will be fixed? (If not, I
think there should be bugs.maemo.org bug tracking the Qt upstream one)
Comment 13 Andre Klapper maemo.org 2010-10-15 12:39:03 UTC
(In reply to comment #12)
> Does that tell in which Maemo version the Qt bug will be fixed?

Yes, if Nokia communicates which Qt version they ship in which Maemo version,
and if Qt version x.y.z on Maemo doesn't differ from upstream Qt version x.y.z,
and if developers close bug reports in Qt bugtracker by adding a comment like
"will be fixed in the next {stable,unstable} Qt release".

If that's not the case it's Nokia to blame.