Qt4-preview-feedback Archive, August 2006
Zoomed QGraphicsView performance issue introduced in recent snapshot?
Message 1 in thread
Hi. I updated my system to use the current qt-copy module from KDE SVN. It
was rsynced two days ago.
Performance of zoomed QGraphicsViews has been impacted severely. I noticed
it when trying the KDE game I ported, but it can be observed also in the
portedcanvas example. Just launch it, grab an item and move it around. Now
zoom the view, and observe the severe lag in updates when doing the same
operation. Mirror mode also shows a noticeable performance hit, even in
non-zoomed views.
Can you reproduce this?
Regards,
Mauricio Piacentini
Tabuleiro
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 2 in thread
Hi Mauricio,
I can reproduce it on my machine with qt4.2-snapshot-20060821. Additionally
performance significantly drops when you display the mesh in the canvas. Try
adding a sprite to the canvas (watch it moving smoothly) and afterwards add
the mesh to the scene (Edit->Create Mesh). Significant performance loss.
-----Ursprüngliche Nachricht-----
Von: qt4-preview-feedback-request@xxxxxxxxxxxxx
[mailto:qt4-preview-feedback-request@xxxxxxxxxxxxx] Im Auftrag von
mauricio@xxxxxxxxxxxxx
Gesendet: Mittwoch, 23. August 2006 15:56
An: qt4-preview-feedback@xxxxxxxxxxxxx
Betreff: Zoomed QGraphicsView performance issue introduced in recent
snapshot?
Hi. I updated my system to use the current qt-copy module from KDE SVN. It
was rsynced two days ago.
Performance of zoomed QGraphicsViews has been impacted severely. I noticed
it when trying the KDE game I ported, but it can be observed also in the
portedcanvas example. Just launch it, grab an item and move it around. Now
zoom the view, and observe the severe lag in updates when doing the same
operation. Mirror mode also shows a noticeable performance hit, even in
non-zoomed views.
Can you reproduce this?
Regards,
Mauricio Piacentini
Tabuleiro
To unsubscribe - send "unsubscribe" in the subject to
qt4-preview-feedback-request@xxxxxxxxxxxxx
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 3 in thread
Hi everyone,
This also relates to Mauricio's recent post:
Re: Zoomed QGraphicsView performance issue ...
I'm Ian Wadham, from Australia, the current author of KGoldrunner,
an arcade game in the KDE 3 games library. The game runs in a
28x20 grid of 16x16 pixel tiles. They are automatically scaled up
to 20x20 or 28x28 pixels at 800x600 or higher resolutions, using
QWorldMatrix in Qt 3 or QMatrix in Qt 4.
I have just rebuilt KGoldrunner, at about 5:00 AM GMT on Thursday,
24 August, using the latest Qt 4 snapshot and latest KDE 4 source
code from KDE SVN repository. When I went to play KGoldrunner,
the performance was catastrophic ... about 2 animation steps per second
when there should be about 20. It was the same at all scaling factors,
1.75, 1.5 and 1.25, but normal performance resumed when the scaling
was 1.0, but then (on my screen) the runners are only about 3 mm high!
I would suggest that something bad has happened to QMatrix or the
way in which it is used in QGraphicsView.
Well I'm writing about more subtle performance problems. I did
my build in order to investigate them in more detail. I won't be able
to do much until the scaling problem is fixed, but I'll talk about my
plans anyway.
In KGoldrunner, the tiles contain bricks, concrete, ladders, etc. forming
a maze that you (represented by the hero, a green runner) must navigate
and pick up pieces of gold. In many levels there are enemies (blue runners)
whom you must avoid. The puzzle called Initiation, level 2, Lust for
Gold is the one Mauricio Piacentini was using to test his conversion of
KGoldrunner to Qt 4 and QGraphicsView, when he started this thread.
You can get direct to it by using menu Game->Play Any Level and a dialog
box, to see what it looks like in KDE 3/Qt 3/QCanvas. It starts with two
enemies at the top left of the picture and the hero at the bottom right. By
pointing the mouse at the bottom left, you cause the hero to run left and
pick up a large number of gold pieces (causing tile re-draws). Meanwhile
the enemies run right and then down a ladder, to try and catch the hero.
A second or two into this scenario there is (or was - it's all slow today)
a distinct slowdown in the animation (Mauricio calls it a "hiccup"). It
appears to happen when enemy steps and hero steps coincide in time
(each is a quarter of a tile at about 50 msec intervals, though the enemies
and the hero have individual QTimers, running at different rates). When
this coincidence happens, there are more than a few rectangles to re-draw,
some at the top left and some at the bottom right, and QGraphicsView
decides to "unite()" them into one huge rectangle (about half the view),
hence the hiccup ... or so Mauricio and I believe.
On 21 August 2006, Mauricio Piacentini wrote:
> I believe it could be a particular case, due to the size of the items
> and the pattern of update and item arrangement. This particular game has
> hundreds of levels, and the problem only occurs in 3 or 4 of them, and
> only with a particular timing, which is fortunately easy to reproduce on
> one of the levels (level 2 of Initiation, just at the start.) This is
> the source of the logs I posted last week. So you are probably correct
> that in 95% of the time the optimization threshold is effective, but
> there are situation where it definitely fails to produce the best results.
Well I certainly haven't tested all the levels with Qt 4. That would take
many hours. I simply selected about 6-10 levels that I knew to be
time-critical.
I have tested all the levels in the KDE 3/Qt 3/QCanvas version at some time
or another and there are no timing problems there. Nor were there any in
earlier (Qt 1) versions of KGoldrunner that just drew and erased pixmaps
on a widget (back before QCanvas was released).
Ignoring, for the moment, the present catastrophic slowdown in scaled
views, I am concerned that QGraphicsView might not be as reliably
efficient as QCanvas was in handling sprites that change shape as they
move (such as a running man), nor in handling parts of the landscape that
change appearance (e.g. when a man collects a bag of gold). It was I
who guessed that a 20-rectangles threshhold in the QGraphics code might
be causing our hiccup, but I suspect there may be other inefficiencies
in handling simple animations using QGraphicsView.
So I propose to do some further investigation, just in case. For example,
QCanvasSprite had a "move (x, y, animationFrame)" method, to change
the position and shape of the sprite simultaneously, but in a QGraphics
pixmap item you have to do a "setPos" and "setPixmap" separately.
Does that affect animation performance? If so, how?
I'll start a new thread (subject) when I have something further to report.
Cheers, Ian Wadham
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
