[Kde-games-devel] Adventures with Palapeli

[Ian Wadham]

On Wednesday 09 December 2009 7:54:26 pm Stefan Majewsky wrote:
> Am Mittwoch, 9. Dezember 2009 00:17:15 schrieb Matthew Woehlke:
> > This, at least (slowness dragging 800 pieces) isn't /horribly/
> > surprising, though... that gives me a thought; I wonder if the problem
> > is Z ordering? Due to how the shadows work, does pala have to repaint
> > all 800 pieces to join the 801'st?
> >
> > Ian, if you are wanting to play around, I would look if there is Z-order
> > changing that happens when joining pieces, and if yes, try turning it
> > off. Hmm... but fixing this might take some doing, I'm not sure it's
> > trivial to just fiddle with the Z order without introducing other
> > glitches.
> 
> I think I'll give a comment on how it's supposed to work. First some
> terminology: A single image is called "piece", while a group of pieces that
>  is moved in a group is called "part". That means: A part is a
>  QGraphicsItem that contains multiple pieces.
> 
> Palapeli makes extensive use of explicit Z-reordering, but only in two
> instances:
> 1. When you start to drag a part, it's raised above all other parts (see
> Part::mousePressEvent).
> 2. Inside the part, the shadow items have a lower Z value than the pieces.
>  The shadow items are *not* direct childs of the piece items, because this
>  would cause some shadows to overlap over pieces in the same part.
> 
> I honestly don't see much room for change in this model. The most promising
> optimisation from my POV would be to merge the pieces in one part into a
> single image.
> 
"One can theorise until the cows come home, but there is no substitute for a
simple experiment." Lord Rutherford.  Well actually, I made that up ... :-)

Here are some timing figures from palapeli/engine/part.cpp:

0 msec after QGraphicsItem::mouseReleaseEvent(event)
233 msec after searchConnections()
290 msec after partMoved()
4072 msec after setCursor() x 834
4072 msec after Palapeli::Part::mouseReleaseEvent(event)

Most of the time is being taken up by the loop on "piece->
setCursor(Qt::OpenHandCursor);", which is performed for all
solved pieces.  Should it not be for just the one piece that is
added to the solution?  One setCursor takes about 5 msec.

Also, I do not see a "hand" cursor any more on my setup.
Didn't you change the cursor style, Stefan?

If I comment out the setCursor loop (this has no visible effect BTW),
the piece-placement animation becomes visible and proceeds at a
nice speed, much as with a smaller puzzle.

0 msec after QGraphicsItem::mouseReleaseEvent(event)
235 msec after searchConnections()
292 msec after partMoved()
292 msec after setCursor() x 0
292 msec after Palapeli::Part::mouseReleaseEvent(event)

Forward to 1000+ piece puzzles in KDE 4.5! ... :-)

All the best, Ian W.

P.S. Would you like me to send you my 1000-piece test-case
privately, Stefan?  It has some edge pieces lined up next to where
they fit, so it should be nice and easy to use.

P.P.S. The "move whole solution-part" operation is still slow, even
with the commented-out setCursor loop.