302843 - [10.3] Java Solitaire game applet slow, unresponsive to mouse input

Status: RESOLVED WORKSFORME

(Camino Graveyard :: Plug-ins, defect)

Description

[Joseph Schwarz]

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.

Comment 1

[Samuel Sidler (old account; do not CC)]

Is this a JEP problem?

Comment 2

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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?

Comment 4

[Joseph Schwarz]

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.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

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

Comment 6

[Samuel Sidler (old account; do not CC)]

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

Comment 7

[Samuel Sidler (old account; do not CC)]

Updating summary to show 10.3-only.

Can someone try on 10.2?

Comment 8

[Steven Michaud [:smichaud] (Retired)]

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

Comment 9

[Steven Michaud [:smichaud] (Retired)]

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)?

Comment 10

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

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

Comment 12

[Joseph Schwarz]

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

Comment 13

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

> 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 :-)

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 17

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 18

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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 ;)

Comment 19

[Torben]

I see the top card problem almost 100% of the time.
PB12" 867/640, 1.5Mbs ADSL, 10.3.9

Comment 20

[Steven Michaud [:smichaud] (Retired)]

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

Comment 21

[Steven Michaud [:smichaud] (Retired)]

> task-switching efficiency

I should have said "thread-switching efficiency" or "efficient handling of
multiple threads".

Comment 22

[Steven Michaud [:smichaud] (Retired)]

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

Comment 23

[Samuel Sidler (old account; do not CC)]

Joseph, does the latest JEP fix this bug for you? If so, we'd like to go ahead and close it.

Comment 24

[Joseph Schwarz]

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.

Comment 25

[froodian (Ian Leue)]

WFM on behalf of reporter.

Comment 26

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 27

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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?

Comment 28

[Steven Michaud [:smichaud] (Retired)]

I can no longer reproduce this problem at all with JEP 0.9.5+g and
either Camino 1.0.2 and Firefox 1.5.0.6 (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)?

Comment 29

[Torben]

> 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 :-(

Comment 30

[Steven Michaud [:smichaud] (Retired)]

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

Comment 31

[Torben]

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

Comment 32

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 33

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

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.

Comment 34

[Joseph Schwarz]

I'm now on Java for Mac OS X 10.4, Release 6 and Camino 1.5.4 and it's still fine.