User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050730 Camino/0.9a2+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050730 Camino/0.9a2+ This applet (my favorite online Solitaire game) was working fine with an earlier alpha release of Camino 0.9. With the most recent one, the playing field doesn't redraw properly after a mouse click (e.g., to deal the next three cards or to move a card from one pile to another). Reproducible: Always Steps to Reproduce: 1. Load/start the applet 2. Play the game a bit 3. Actual Results: After the first couple of moves the game became extremely sluggish. A certain card would appear to be exposed at the top of the game panel, but on trying to drag it with the mouse it turned out that the deck hadn't finished updating and another card got dragged instead! Expected Results: Reliable reproduce the current state of the deck and the various piles of cards.
Is this a JEP problem?
I played this Solitaire game nine or ten times (altogether) in the latest Camino nightlies (2005-07-30-08 and 2005-07-31-08, which include the Java Embedding Plugin), Camino 0.9a2 and Firefox 1.0.6 (using the Java Embedding Plugin from the /Library/Internet Plug-Ins/ directory). I had no problems at all. Out of curiosity I tried the 7-31 Camino nightly without the JEP (so that it used Java 1.3.1 via Apple's Java Applet.plugin). No speed differences, and it worked exactly the same way. For all of these tests I used OS X 10.4.2 (Tiger). I have no idea what the cause of the reporter's problem might be. I'd suggest restarting the computer, to see if that makes any difference.
FWIW, I saw the part about the top card not really being the top card with 2005073008 (v0.9a2+) (bundled JEP) on 10.3.9. I didn't notice any sluggishness, though. Reporter, what version of Mac OS X are you using?
Sorry, I should have mentioned that I'm using Mac OS X 10.3.9 (and yes, earlier Camino builds did work OK with this version). For what it's worth, the applet runs properly with Safari.
> FWIW, I saw the part about the top card not really being the top card with > 2005073008 (v0.9a2+) (bundled JEP) on 10.3.9. > I should have mentioned that I'm using Mac OS X 10.3.9 I've redone my tests on Mac OS X 10.3.9, and have now seen the "top card" problem for myself ... but only in recent trunk versions of Camino (i.e. the 7-30 and 7-31 nightlies and Camino 0.9a2), and not in any other Mozilla-family browser (i.e. not in Camino 0.8.4, Firefox 1.0.6 or Deer Park Alpha 2). I figure this is a bad interaction between the "spurious updates" problem (significantly worsened in recent trunk versions of Camino) and my workarounds for it. Needless to say, this is a _very_ obscure problem, which will not be easy to fix. Here's a quick summary of the current state of my knowledge. Other testers, please fill this in with more detail, or let me know if parts of it seem to be wrong: The real problem here is the "top card" problem -- it's not a speed problem. The "top card" problem doesn't happen at all on Tiger (OS X 10.4.X), in any Mozilla-family browser, in either version of Java supported by JavaEmbeddingPlugin.bundle (1.4.2 or 1.5). It does happen in Panther (OS X 10.3.X), but only in recent trunk versions of Camino (and only when using Java 1.4.2). When the "top card" problem does happen, it happens _often_ -- virtually every time you click on the top-left pile to get the next three cards, then try to draw from the pile of exposed cards just to its right, the card you end up with is different from the one that first seemed to be on top.
So I'm wondering... is this a problem with the nightlies for Firefox/DP? If so, this isn't a Camino-specific problem and will cause issuse if FF/DP ever switches to JEP. Confirming per comment 5 (though this may not be a Camino issue).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updating summary to show 10.3-only. Can someone try on 10.2?
Summary: Java Solitaire game applet slow, unresponsive to mouse input → [10.3] Java Solitaire game applet slow, unresponsive to mouse input
> When the "top card" problem does happen, it happens _often_ This was too optimistic. I've been redoing my tests (still on OS X 10.3.9), and though I'm still able to reproduce the problem in Camino 0.9a2 and the 7-30 nightly, it happens much less often than I first thought. On a hunch that the problem might be worse when the JVM had just been started for the first time, I tried restarting my computer ... but that seemed to make no difference. Oddly, I'm simply unable to make the problem recur in the 7-31 Camino nightly. But just now I had it happen several times in a row in the 2005-07-31-07-trunk Firefox/DeerPark nightly. I think we need more tests ... a lot of them. I the meantime I will try temporarily disabling bits and pieces of the Java Embedding Plugin code to see if this has any effect, one way or the other.
I retried my tests on Tiger with the Camino 7-30 nightly and the DeerPark 2005-07-31-07-trunk nightly (I played five or six games all the way through on each) -- no problems. And I did the same tests (for the first time) on Jaguar (OS X 10.2.8) -- again no problems. Joseph: About how often do you see the "top card" problem? (Number of times per game, and/or percentage of the time the "top" card turns out to be different than expected. Do you occasionally see the problem several times in a row, like I have?) Does it also happen with the Camino 7-31 nightly (you've been using the 7-30 nightly)? If you're willing to go to a bit more trouble, please install the Java Embedding Plugin (from http://javaplugin.sourceforge.net/) to your /Library/Internet Plug-Ins/ directory and try out the 2005-07-31-07-trunk Deer Park nightly (or any other Mozilla-family browser that doesn't already include the Java Embedding Plugin). (The only browsers that do include the JEP are the Camino nightlies starting with 7-29.) Are you able to test on other OS versions (like OS X 10.4.2 or 10.2.8)?
I've now found a more reliable way to reproduce this problem in contexts where it can (presumably) happen at all -- for me it "works" about once in five or six tries. As a result, the ground has shifted a bit: I've now seen the "top card" problem in all Mozilla-family browsers (those I tested) on Panther (Mac OS X 10.3.9), but in none of them on Tiger (OS X 10.4.2) or Jaguar (OS X 10.2.8). I tested with Firefox 1.0.6, Deer Park Alpha2, the 2005-07-31-07-trunk Deer Park nightly, Camino 0.8.4, Camino 0.9a2, and the 7-30 and 7-31 Camino nightlies. (I also tested Safari on OS X 10.3, and didn't see the problem.) Here's my procedure: Click on "New game" and then rapidly click exactly seven times on the spot where the face-down draw pile will (eventually) be dealt (in the upper left part of the "table"). (It helps if you wait to do this until the cards below have almost finished being dealt.) Then "draw" the top card off the face-up draw pile -- it should fairly often "change" to a different card as you draw it. Even with my new procedure, the "top card" problem continues to occur in clusters -- you can go ten or more times without it happening, then see it two or three times in a row.
Created attachment 191302 [details] Illustration of the problem (not a fix) I've found a way to stop the "top card" problem from happening. But it's not really an acceptable solution because it involves turning off the fix (introduced in JEP 0.9.3) for a _different_, equally obscure, problem. I will need to look for a way to resolve _both_ problems at the same time. This (if it works) won't be the first time I've squared the circle in the Java Embedding Plugin ... but doing the impossible usually takes a bit longer than the very difficult :-) For those who are curious, I'm appending a patch (just for illustration) that turns off the one fix to "fix" the other problem. You'll notice that the change only effects Panther (the problem with http://java.sun.com/j2se/jre_check/index.jsp doesn't happen in Jaguar, and has a different fix in Tiger). > I figure this is a bad interaction between the "spurious updates" problem > (significantly worsened in recent trunk versions of Camino) and my > workarounds for it. Turns out I was wrong -- the "top card" problem is unrelated to either the "spurious updates" problem(s) or to my workarounds for it/them.
(In reply to comment #9) > I retried my tests on Tiger with the Camino 7-30 nightly and the DeerPark > 2005-07-31-07-trunk nightly (I played five or six games all the way through on > each) -- no problems. > > And I did the same tests (for the first time) on Jaguar (OS X 10.2.8) -- again > no problems. > > Joseph: > > About how often do you see the "top card" problem? (Number of times per game, > and/or percentage of the time the "top" card turns out to be different than > expected. Do you occasionally see the problem several times in a row, like I > have?) Sometimes I do see the problem several times in a row. Here's one run through the deck: #1 top card is correct, but when I drag it a bit and release it, it doesn't return to the deck until I click again #2 started out as 10 hearts but turned out to be 3 diamonds #3 correct top card, but when I clicked to advance the deck, the same card continued to be displayed #4 when I dragged #3 a bit #4 finally showed up #5 OK #6 OK #7 OK, but again, the top card didn't want to return to the deck when I nudged it a bit #8 OK Then I clicked to cycle the deck back to the beginning, but the display didn't change. A second click not only cycled the deck back but dealt the first card of the new cycle which turned out not to be the real top card when I tried to drag it > > Does it also happen with the Camino 7-31 nightly (you've been using the 7-30 > nightly)? It still occurs (no change as far as I can see) with Camino 2005080108 (v0.9a2+) > > If you're willing to go to a bit more trouble, please install the Java > Embedding Plugin (from http://javaplugin.sourceforge.net/) to your > /Library/Internet Plug-Ins/ directory and try out the 2005-07-31-07-trunk Deer > Park nightly (or any other Mozilla-family browser that doesn't already include > the Java Embedding Plugin). > > (The only browsers that do include the JEP are the Camino nightlies starting > with 7-29.) Unfortunately, I haven't got the time to do this, but your later comments seem to indicate that you've done it already. > > Are you able to test on other OS versions (like OS X 10.4.2 or 10.2.8)? > No, this is the only version of Mac OS X that I have access to. >
Joseph, Thanks for the information. It sounds like you're able to reproduce the "top card" problem much more easily than I've been able to. I _hope_ that your experience isn't typical :-) Like you, I also saw (once or twice in my more than 100 tests) cases of a card (or pile of cards) "stuck" on the journey from one location to another. I, too, "fixed" the problem by clicking the mouse on them. I assume this is part of the same problem ... but I saw it too seldom to really be sure. As you'll have seen in my previous comment, this problem is going to be very difficult to resolve. Since I'll be away all next week, it'll probably be at least several weeks before I can come up with an acceptable solution.
So far I've only had the chance to play the initial game referenced in comment 3, but I had the "top card is not the top card" problem pretty consistently late in the game. I don't know if the length of time I had been playing was really the factor, since I was dealt a very good set of cards below and didn't start going to the stack of cards until some time in the game. I'll see about generating some more "data" :-) on how often that problem appears.
Component: General → Plug-ins
> I'll see about generating some more "data" :-) on how often that problem > appears. I'd really like to hear how often you see the "top card" problem in, say, 30 runs of the "procedure" I described in comment 10. That'd give me an idea how much more often you see the problem than I do. Then you can play a few more hands just for the fun of it :-)
Following the procedure in comment 10, I saw the wrong card 25 out of 30 times (and twice when clicking 7 times rapidly, the clicks on the pile didn't register until much later; one time I had the right card, one the wrong card). On the other hand, playing a couple of hands seems very "laggy" tonight; cards aren't snapping to the position on top of other cards, and it's slow enough in some cases flipping cards that most of the time you can tell only two cards are flipped two the face-up stack instead of three, and occasionally there are major screen "artifacts" (whiteout/tanout). This seems to match comment 0.
Sigh. (But thanks for the tests.) Maybe the speed of your computer or you connection makes a difference. I have a dual-1Ghz-cpu G4 PowerMac, and a 1.2 mbit DSL connection.
I sometimes have access to a high-speed connection of some sort (unknown), like the other night. Tonight I repeated the test on 56k dialup and got slightly better results: 10 times the card was correct; 20 times it was incorrect. I played a hand and it was just as "laggy" as the other night. It may have something to do with processor speed, though; I "only" have a 1.33 GHz G4 ;)
I see the top card problem almost 100% of the time. PB12" 867/640, 1.5Mbs ADSL, 10.3.9
Smokey: > Following the procedure in comment 10, I saw the wrong card 25 out of 30 > times > It may have something to do with processor speed, though; I "only" have a > 1.33 GHz G4 ;) Torben: > I see the top card problem almost 100% of the time. > PB12" 867/640, 1.5Mbs ADSL, 10.3.9 I found out how to disable one of my CPUs. When I do that I experience the "top card" problem _much_ more often. I also see the "cards not snapping into position" problem quite often just playing the game. So task-switching efficiency (or lack thereof) seems to be the most important factor, followed (at some distance) by raw CPU speed. I re-ran my tests of attachment 191302 [details] using just one CPU -- it seems to fix both the "top card" and the "cards not snapping into position" problems. Now all I need to do is find an another way to make http://java.sun.com/j2se/jre_check/index.jsp render correctly :-) (By the way, if you install the latest version of CHUD http://developer.apple.com/tools/download/, you'll see a "Processor" option in System Preferences that lets you disable all but one of multiple CPUs. CHUD only works on OS X 10.3.X or 10.4.X.)
> task-switching efficiency I should have said "thread-switching efficiency" or "efficient handling of multiple threads".
I've just released a new version (0.9.5+e) of the Java Embedding Plugin that (I think) fixes this bug: http://javaplugin.sourceforge.net/ Please follow the Readme's instructions to install the new JEP to your /Library/Internet Plug-Ins/ folder, and to remove older copy(ies) of the JEP from your Mozilla.org browser(s).
Joseph, does the latest JEP fix this bug for you? If so, we'd like to go ahead and close it.
I just tried it out on build 2006090104 (1.0+) & Mac OS 10.4.7 and it looks very good. I played one complete game and didn't see any of the problems I had seen previously.
WFM on behalf of reporter.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
Since this was reported as a 10.3-only bug, it shouldn't be closed based on a 10.4 WFM report. I'll try to check this out later today.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: [10.3] Java Solitaire game applet slow, unresponsive to mouse input → [10.3] Java Solitaire game applet slow, unresponsive to mouse input
This is still very plainly obvious in 10.3.9 on the 18branch (JEP 0.9.5+g); in fact, I think it's worse than it was before. In a single game, I had both cards in the "draw" stack not displaying the proper card as well as several cards down on the playing field. Torben, do you still see this bug on your 10.3.9 box, too?
Assignee: mikepinkerton → nobody
Status: REOPENED → NEW
QA Contact: plugins
I can no longer reproduce this problem at all with JEP 0.9.5+g and either Camino 1.0.2 and Firefox 18.104.22.168 (on OS X 10.3.9). I turned off one of my CPUs and used the procedure I describe in comment #10 (as I say in comment #20, turning off one CPU used to be a good way to make this problem happen more often). Smokey, do you find that the problem you see only happens on certain versions of Camino and/or Firefox (all testing with JEP 0.9.5+g, of course)?
> Torben, do you still see this bug on your 10.3.9 box, too? Yes, just tested with a current trunk build (JEP 0.9.5+g). Can't say it's worse than before but not any better either :-(
Here are some more questions for both Smokey and Torben: Does the problem also happen in Safari? Do either of you have anything set in the Java Control Panel's "Java Runtime Parameters" box? (And if so what are they?) Does adding the following to your runtime parameters make any difference? -Dapple.awt.graphics.EnableLazyDrawing=true (Torben, I thought you were running OS X 10.2.8.)
> Does the problem also happen in Safari? No problems for me (ver. 1.3.2) > > Do either of you have anything set in the Java Control Panel's "Java > Runtime Parameters" box? (And if so what are they?) Since I didn't even know there was such a thing, probably not. But I'll take a look if you can tell me where to find it. > Does adding the following to your runtime parameters make any > difference? > > -Dapple.awt.graphics.EnableLazyDrawing=true Where do I do this? > (Torben, I thought you were running OS X 10.2.8.) I run 10.2.8 at work, 10.3.9 at home.
The "Java Control Panel" is Applications : Utilities : Java : Java 1.4.2 Plugin Settings. When you run it you'll see the Java Runtime Parameters box towards the bottom of the window. Just paste in -Dapple.awt.graphics.EnableLazyDrawing=true, "Apply", and close the window (you'll also need to restart your browser if it's running). Let us know your results.
So far, I can easily reproduce this problem with a pre-Camino 1.0.3 build, recent Camino 18branch build, recent Camino trunk build and Firefox 2.0b2 (all have +g). I haven't yet checked other Firefoxen. Safari does not exhibit the problem. I have no Java parameters set; I'll try with your parameter later.
I'm now on Java for Mac OS X 10.4, Release 6 and Camino 1.5.4 and it's still fine.
Status: NEW → RESOLVED
Last Resolved: 13 years ago → 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.