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.
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