Bug 255933

Thanks for the report. This is a known issue. It's easy enough to fix with a hack, but I've been hoping to come up with an elegant solution for a while now. Sorry for the inconvenience.

An easier workaround is to just resize the window, which should force the cards to update themselves. A quick maximize/restore should be enough.

This bug seems to be fixed in revision 1207784.  I'm the reporter, and I'm marking the bug fixed.

Actually, it hasn't been fixed. (Most likely your card image caches are full of all the sizes you regularly use, so the issue has stopped appearing for you.)

I'm reopening so that I can assign duplicates to it. I also now hope to finally have the time to fix it.

*** Bug 262375 has been marked as a duplicate of this bug. ***

*** Bug 262368 has been marked as a duplicate of this bug. ***

SVN commit 1212966 by coates:

Make cards check that their size is correct before painting.

If a card is asked to paint() but it's current pixmap differs in size
from the current deck card size, it now explicitly requests a new a new
pixmap from the deck.

This will hopefully fix all the recent issues with cards having the
wrong size or not appearing at all. Technically, they were always
appearing, but sometimes they were appearing at a size of 0 by 0 pixels.
:)

BUG:255933

 M  +6 -0      kabstractcarddeck.cpp  
 M  +2 -0      kabstractcarddeck.h  
 M  +9 -0      kcard.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1212966

SVN commit 1212968 by coates:

Backport of commit 1212966.

Make cards check that their size is correct before painting.

If a card is asked to paint() but it's current pixmap differs in size
from the current deck card size, it now explicitly requests a new a new
pixmap from the deck.

This will hopefully fix all the recent issues with cards having the
wrong size or not appearing at all. Technically, they were always
appearing, but sometimes they were appearing at a size of 0 by 0 pixels.
:)

CCBUG:255933



 M  +6 -0      kabstractcarddeck.cpp  
 M  +2 -0      kabstractcarddeck.h  
 M  +9 -0      kcard.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1212968

FWIW I could not reproduce cards at different sizes later on, so it was probably cache-related or some such. I also noticed a case or two of empty deals when I started to play but persevered and they went away. I assume all this was because I had just built a completely new copy of trunk in new directories with new config files (KDEHOME), etc.

*** Bug 262604 has been marked as a duplicate of this bug. ***

*** Bug 262671 has been marked as a duplicate of this bug. ***

*** Bug 263172 has been marked as a duplicate of this bug. ***

i confirm, its present in 4.6 RC2.

but since the patch is about a week old, I suppose RC3 will be OK, right?

I'm not sure if there's going to be a third RC, but yes, the fix has been backported to the 4.6 branch and will appear in SC 4.6.0.

i have checked out trunk (last changed revsion: 1212966) and there seem to be some issues left.

while i haven't encountered invisible cards anymore, sometimes the card piles are not stacked properly. in games of gypsy or grandfather clock all (initial) cards from one pile sometimes occupy the same space, instead of being spaced out. clicking on the pile or moving cards from/to the pile rearranges it properly.

also, upon resizing the window, sometimes not all cards resize properly, so after several resizes, you end up with having many different card sizes. when that happens, CPU usage is 100% [on one core]. i could not reliably reproduce these occurance, but they happened multiple times, and seemed to be related to each other.

Johannes,

The two issues you mention are actually unrelated. Normally I'd ask you to open separate reports for them, but I already fixed the improperly spaced piles issue yesterday.

The missized cards and 100% CPU usage problem is also distinct from the bug reported here, but as the "symptoms" of the two are so similar, it'd probably be easier to keep them both in a single report.

Thanks.

SVN commit 1214866 by coates:

Fix a bug where painting caused near 100% CPU usage and mis-sized cards.

This one was a bit of a doozy. The route of the problem is KImageCache's
in memory pixmap cache was occasionally returning the wrong pixmap for
a given key. Why that was happening I still don't know. So a card would
go to paint itself and notice that its pixmap was the wrong size, so it
would ask for a new one. The KAbstractCardDeck would take the request,
notice that the requested image/size was in the cache and return the
cached version, but unfornuately this was actually the wrong pixmap and
had the wrong size. The card happily used this pixmap and painted itself
but the next time it went to paint it noticed that its pixmap was the
wrong size and the loop repeated, hence the high processor usage.

I've disabled the in memory pixmap cache as the benefit wasn't very
significant and I couldn't figure out what the issue actually was. There
were also some problems with the KCard and KAbstractCardDeck code that
made the problem worse than it should have been. Those have been fixed
as well.

BUG:255933

 M  +6 -1      common.cpp  
 M  +17 -24    kabstractcarddeck.cpp  
 M  +4 -0      kcard.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1214866

SVN commit 1214868 by coates:

Backport of commit 1214866.

Fix a bug where painting caused near 100% CPU usage and mis-sized cards.

This one was a bit of a doozy. The route of the problem is KImageCache's
in memory pixmap cache was occasionally returning the wrong pixmap for
a given key. Why that was happening I still don't know. So a card would
go to paint itself and notice that its pixmap was the wrong size, so it
would ask for a new one. The KAbstractCardDeck would take the request,
notice that the requested image/size was in the cache and return the
cached version, but unfornuately this was actually the wrong pixmap and
had the wrong size. The card happily used this pixmap and painted itself
but the next time it went to paint it noticed that its pixmap was the
wrong size and the loop repeated, hence the high processor usage.

I've disabled the in memory pixmap cache as the benefit wasn't very
significant and I couldn't figure out what the issue actually was. There
were also some problems with the KCard and KAbstractCardDeck code that
made the problem worse than it should have been. Those have been fixed
as well.

CCBUG:255933


 M  +6 -1      common.cpp  
 M  +17 -24    kabstractcarddeck.cpp  
 M  +4 -0      kcard.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1214868