Bug 255933 - Cards are often invisible or incorrectly sized
Summary: Cards are often invisible or incorrectly sized
Status: RESOLVED FIXED
Alias: None
Product: kpat
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR major
Target Milestone: ---
Assignee: Parker Coates
URL:
Keywords:
: 262368 262375 262604 262671 263172 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-11-03 02:53 UTC by Christopher Neufeld
Modified: 2011-01-16 19:41 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Neufeld 2010-11-03 02:53:31 UTC
Version:           unspecified (using Devel) 
OS:                Linux

I'm using svn revision 1191299.  The kpat game has some weird behaviour when playing Spider.  If I play a game using, say, the Egyptian cards, finish the game, then start a new one, the game deals out invisible cards.  I can sometimes make the cards visible again by changing the deck style, but I might have to try six or seven different styles before I find one that I can see.

If I switch to a game of Freecell, using the Egyptian cards, then switch back to Spider, the cards are visible again, for a single game.  When a second new game of Spider is started, the cards are always invisible.  As you find new deck styles that are visible, it seems as if each one is only good for a single deal of the cards before it, too, becomes invisible.  Once again, you can reset this by switching to Freecell before going back to Spider.

Reproducible: Always

Steps to Reproduce:
1.  Play a game of Spider, difficulty level medium.  Finish the game.
2.  Start a new game of Spider.  You cannot see the cards that are dealt out.
3.  Switch to a game of Freecell.  The cards are visible.
4.  Switch back to Spider, the cards are visible.  Finish the game.
5.  Start another game of Spider.  The cards are invisible.

Actual Results:  
The cards cannot be seen or manipulated.

Expected Results:  
The cards should be visible.
Comment 1 Parker Coates 2010-11-03 03:08:54 UTC
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.
Comment 2 Christopher Neufeld 2010-12-20 19:31:40 UTC
This bug seems to be fixed in revision 1207784.  I'm the reporter, and I'm marking the bug fixed.
Comment 3 Parker Coates 2011-01-08 14:07:43 UTC
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.
Comment 4 Parker Coates 2011-01-08 14:08:03 UTC
*** Bug 262375 has been marked as a duplicate of this bug. ***
Comment 5 Parker Coates 2011-01-08 14:13:40 UTC
*** Bug 262368 has been marked as a duplicate of this bug. ***
Comment 6 Parker Coates 2011-01-08 21:32:37 UTC
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
Comment 7 Parker Coates 2011-01-08 21:38:27 UTC
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
Comment 8 Ian Wadham 2011-01-08 22:35:54 UTC
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.
Comment 9 Parker Coates 2011-01-09 00:45:14 UTC
*** Bug 262604 has been marked as a duplicate of this bug. ***
Comment 10 Parker Coates 2011-01-09 17:50:44 UTC
*** Bug 262671 has been marked as a duplicate of this bug. ***
Comment 11 Parker Coates 2011-01-14 21:45:36 UTC
*** Bug 263172 has been marked as a duplicate of this bug. ***
Comment 12 Mathieu Jobin 2011-01-15 18:39:05 UTC
i confirm, its present in 4.6 RC2.

but since the patch is about a week old, I suppose RC3 will be OK, right?
Comment 13 Parker Coates 2011-01-15 18:52:42 UTC
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.
Comment 14 Johannes E. Krause 2011-01-15 19:14:25 UTC
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.
Comment 15 Parker Coates 2011-01-16 19:27:46 UTC
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.
Comment 16 Parker Coates 2011-01-16 19:37:51 UTC
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
Comment 17 Parker Coates 2011-01-16 19:41:37 UTC
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