JDK-4717086 : COMPATIBILITY: hopper-rc Hghlnd Golf applet fails to display graphics correctly
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2002-07-18
  • Updated: 2002-08-21
  • Resolved: 2002-08-20
Related Reports
Duplicate :  
JDK-4374079 - Win32:Lightweight components do not immediately repaint in response to repaint()
Relates :  
JDK-4683253 - REGRESSION: black or mysterious background in Container
Relates :  
JDK-4702044 - GUI update problems with some demo applets on Win2000 an WinXP
Relates :  
JDK-4664490 - REGRESSION: AWT window background isn't drawn on win32 using javaw
Relates :  
JDK-4488406 - Selected cell in SpreadSheet demo repaints incorrectly
Relates :  
JDK-4458337 - Merlin: repaints do not work by using javaw on WinNT if double buffering is disa
Description
Problem: The applet throws netscape.javascript.JSException during loading and fails to display graphics correctly.

Java VM: JRE version 1.4.1-beta Java HotSpot(TM) Client VM
OS/Browsers tested:  WinXP Home/IE6.0
                     Win2000 Pro/IE5.5

The problem is also reproducible on a different machine running same OS/browser.

This applet passes with the MS VM.

STEPS TO REPRODUCE:

1. Install Hopper build 16.
2. Make sure you test the applets OFF SWAN.
3. Go to url: http://www.pogo.com
4. Click on the "Sign In" link at the top of the page.
5. Login as username "snarlwog" and password of "hmuller" *OR* as "KeyMenz"
   with the passord of "b00yah"
6. Click the "Highland Golf" link found under "Arcade"
7. Choose a room to play in or click the "Play Now" button.
8. Play the game.

A netscape.javascript.JSException is thrown when loading the applet.
The applet had some display errors during gameplay. Occasionally the applet 
window goes completely BLACK during transitions from one hole to another. Sometimes clicking on an area of the applet OR minimizing/maximizing the applet window will reveal the game so that you could continue. This is the first time this behavior has been observed.  This applet passed with build 11 of Hopper.

Java Console Output:

Mon Jun 10 13:13:42 MDT 2002 Thread-941 exception
netscape.javascript.JSException: Unknown name.
jvm test passed
Mon Jun 10 13:13:42 MDT 2002 thread applet-u.Applet stop
Mon Jun 10 13:13:42 MDT 2002 thread applet-u.Applet destroy
copyright (c) 1996-2001 pogo.com. all rights reserved.
http://www.pogo.com/
Build 5.0.6.20 Mon Jul 1 03:34:16 2002
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Java 1.4.1-rc (Sun Microsystems Inc.) Windows XP 5.1 (x86)
Mon Jun 10 13:13:43 MDT 2002
SoundPlayer: voodoo ON
Started inval queue : Q.e@132e1b6
Mon Jun 10 13:28:31 MDT 2002 React-golf01.pogo.com:18005-1 died

IntermissionApplet.init: time=40 refTime=1023737310436
gameUrl=http://golf01.pogo.com/game/arcade/golf.jsp?scrn=KeyMenz&site=pogo&ctim=1023736407451&anam=Extreme+Golf&rspt=19811&ahst=golf01.pogo.com&lkey=3d21a8f10390e8810a66fd3e0000283c&asnm=golf-plgfsf11&rhst=play20.pogo.com&game=golf&size=m&intermissionState=9%2C2%2C4%2C4%2C3%2C9%2C4%2C3%2C5%2C4%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2C35%2C0%2C%2B3%2C0%2C%2B3%2CscriptHole10.txt%2Cnull%2C1615%2C155%2C1

Started inval queue : Q.e@ba0dd4

IntermissionApplet.showDocument("http://golf01.pogo.com/game/arcade/golf.jsp?scrn=KeyMenz&site=pogo&ctim=1023736407451&anam=Extreme+Golf&rspt=19811&ahst=golf01.pogo.com&lkey=3d21a8f10390e8810a66fd3e0000283c&asnm=golf-plgfsf11&rhst=play20.pogo.com&game=golf&size=m&intermissionState=9%2C2%2C4%2C4%2C3%2C9%2C4%2C3%2C5%2C4%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2Cnull%2C35%2C0%2C%2B3%2C0%2C%2B3%2CscriptHole10.txt%2Cnull%2C1615%2C155%2C1",
"_self")

InvalQueue thread exiting: InvalQueue-1-Q.yb[panel41,0,0,142x16,layout=java.awt.BorderLayout]

Mon Jun 10 13:29:19 MDT 2002 Painter - scriptScorecard.txt Canvas 0 ts.connect(address 'golf01.pogo.com' port '18005' game 'golf' lkey '3d21a8f10390e8810a66fd3e0000283c' uid
'4443860927259682' site 'pogo')

Mon Jun 10 13:29:19 MDT 2002 Painter - scriptScorecard.txt Canvas 0 lkey is: 3d21a8f10390e8810a66fd3e0000283c

Mon Jun 10 13:29:19 MDT 2002 React-golf01.pogo.com:18005-2 run

Mon Jun 10 13:29:19 MDT 2002 tkping

Trace Log Output:

None
Comments
WORK AROUND Add Toolkit.getDefaultToolkit().sync(); in render() method after the rendering is done, or invoke rendering on EDT by using EventQueue.invoke[Later/andWait](). ###@###.### 2002-08-20
20-08-2002
EVALUATION I tested with build 16 & 11. netscape.javascript.JSException was there for build 11. So that is not a regression. Also I can't see the applet goes black during transition from one hold to another. ###@###.### 2002-07-18 Tested in Windows98 SE with b17, the applets runs fine. Can't reproduce the bug. ###@###.### 2002-07-22 Tested on Windows 2000 with b17 on IE 5.5 SP2. Was able to reproduce the problem. Applet started and run fine 'till the end of the game. Then, instead of starting a new game, the applet's area got painted in black. When I was bringin the Java Console over the window, it did not get repainted properly, but when I was covering only part of the applet's area with Java Console (or any other) window, part of the applet was repainting. After re-starting the browser, or reloading a page I was able to see the problem again. Some parts of the applet area would not be repainted properly and would stay black. Tried this 3 or 4 times and every time could see the problem. Either the whole applet area would not get repainted, or some part of it. Re-assigning to AWT team for further investigation of the repaint problem. ###@###.### 2002-07-25 According to the test results at: http://sqesvr.sfbay.sun.com/deployment3/status/applet_compat/hopper/applet_compat_results.html this applet passed with hopper build 11, but failed with hopper build 16. We should test to make sure this is accurate. ###@###.### 2002-07-31 Name: dmR10075 Date: 08/07/2002 I confirm that bug is reproducible with Hopper b16 and b18. I was unable to reproduce it with mantis build. Here is how I reproduced it 1. Wait till applet starts and first image with "Start" button appears. 2. Move some window to cover some part of the applet. 3. Click on the other visible part of the applet to bring applet's window on top. Notice that some part of the applet which was under the window became redrawn and looks good, but some part of it doesn't get redrawn and looks black. Notice also, that when it becomes black it happens AFTER other parts (before hidden) get redrawn. If you unable to see the same on the first window, click on "Start", wait till next image - golf field - appears and repeat steps 2 and 3. I examined the applet, and think: They have some special thread which they use to perform drawing operations. I suspect it works as following: they add some area to the list of areas to be painted, then request draw operation - and this thread extracts area and call paint method of some components. Not sure why do they do this, may be because they had the problem with identifying paint area when paint events arrives? Anyways, I think that problems may happen because of this thread. If we look back at the way I reproduced the bug we will see that problems happen when there are two simultaneous paint operations exits - in our case they are on EDT and their thread. What happens if two threads both access one graphics (or surface data) and set clip areas, then clear it, then paint in it. Also, it is unclear how do they handle external paint requests (like when some part of the window becomes visible). When I saw black parts of the applet I took some external window and wanted to move it over the applet to force it to redraw the hole applet's area. When external window's rect crossed the applet's black area by one pixel the whole black area became redrawn and started to look normal. It seems that they doesn't respect clip area and paint area set by AWT for paint() but use their own areas. However it is possible that it is still our bug. ###@###.### 2002-08-07 ====================================================================== Name: ssR10077 Date: 08/13/2002 ###@###.### 2002-08-13 I've developed minimized test case reproducing the problem. <HTML> <HEAD> </HEAD> <BODY bgcolor="#ffffff"> <applet codebase="." code=test.class height=400 width=533 VIEWASTEXT> </applet> </BODY> </HTML> import java.applet.Applet; import java.awt.*; public class test extends Applet implements Runnable { boolean redraw = false; public void paint(Graphics g) { redraw = true; } public void start() { Thread t = new Thread(this); t.start(); } public void run() { while (true) { if (redraw) { redraw = false; Graphics g = getGraphics(); Rectangle r = getBounds(); g.setColor(Color.RED); g.fillRect(r.x, r.y, r.width, r.height); g.dispose(); } try { wait(1); } catch (Throwable e) {} } } } It doesn't look like an AWT issue. Should consult with 2D team. ====================================================================== I updated the "See also" list with a bunch of bugs that Sergey reported as having similar symptoms. However, we don't know for sure how closely they are related. If information/work/support from AWT is needed for this bug, please contact ###@###.###. ###@###.### 2002-08-13 The problem is reproducible with appletviewer as well, but not with applications. First appered in 1.4. So far it looks like if rendering happens on thread other than EventDispatchThread, the rendering often doesn't appear, unless Toolkit.sync() is called. When the applet above was modified to render on EDT (by using EventQueue.invokeLater or invokeAndWait), everything worked fine. ###@###.### 2002-08-20
20-08-2002