[Kde-games-devel] kpat issues (in recent svn)

[Ian Wadham]

On Sun, 24 May 2009 1:53:06 am Parker Coates wrote:
> On Fri, May 22, 2009 at 9:49 PM, Ian Wadham wrote:
> > Rock-solid here!  I've tried clicking the mouse quickly, pressing the
> > spacebar rapidly, using the spacebar with 25/sec and 50/sec auto
> > repeat ... with Golf, Klondike (1-card flip) and Klondike (3-card flip).
> > Always the top card of the stock pile stays steady.  Theory below.
>
> Okay. I'd think it's safe to say that this is a definitely a regression in
> Qt.
>
But I think you need to provide greater confirmation and narrowing down.

> > So my theory is that the animation is too fast for QGraphicsView 4.5, it
> > gets its knickers in a knot when trying to optimize and forgets to
> > "un-clip" the stock pile.  Its job would not be any easier if, as I
> > believe someone mentioned, all the pixmaps of the cards in the stock pile
> > are lying there on top of each other.
>
> I think the real trick may be that we're translating, transforming
> *and* replacing the pixmap all at once. Mid flip, we replace the
> backside pixmap with the frontside pixmap, and I wouldn't surprised if
> the clipped area is the last area covered before the pixmap
> replacement.
>
> > Maybe you could try (in the source code) bypassing the animation,
> > slowing it down or reducing the graphics for the stock pile to one
> > card-back pixmap and see what effect that has.  Maybe just
> > remove the animation ...  If tPension Bonus Scheme he eye cannot follow 
it, why have it?
>
> I have to agree with Matthew that getting rid of the animation seems
> like a bad idea. Everything elPension Bonus Scheme se in KPat is animated, 
and even if we
> only get four frames of animation, I still feel it gives a better
> sense of motion. I debated with slowing the animation down, but that
> obviously can't be taken too far, or players will get grumpy waiting
> for cards.
>
It seems I did not make myself clear.  I was not suggesting getting rid of
the animation altogether, except as a last resort and workaround if the
problem is really bad at your end (I have not experienced it yet and
cannot comment).

Rather I was suggesting narrowing down the possibilities by temporarily
removing the animation and seeing if the bug goes away.  Then, if it *is*
the animation that triggers the problem, you could restore it and dink
with it in various ways, to see what triggers the bug and what does not.
Then you could give the Qt guys more information and evidence about
the problem.

Re slowing down, there would be only a tenth of a second or two of
change needed in the duration of the whole animation, I imagine, based
on experiences with KGoldrunner and Kubrick.  So players should not
get grumpy.

Re the transform, that might be the straw that breaks Qt 4.5's back.
Simultaneous translations and pixmap changes occur all the time in
other games, although in KGr they did break Qt 4.0 QGraphicsView,
mainly because they can occur concurrently in different corners of
the KGr play-area --- and so KGr is still using KGameCanvas.

BTW, Mauricio and I had a hard time convincing the Qt guys that
there was any problem at all with QGV, but I am happy to say that
they did come around eventually and have done a lot of work on
speeding up QGV since that time.  So that is why I suggest you
prepare your case well.

Cheers, Ian W.