JDK-4693644 : REGRESSION,JCK1.4: api/java_awt/interactive/LWComponentTests.html fails
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_98,windows_nt,windows_xp
  • CPU: x86
  • Submitted: 2002-05-30
  • Updated: 2002-06-26
  • Resolved: 2002-06-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.1 rcFixed
Related Reports
Relates :  
JDK-4409306 - W2K: mouse and menu flicker occurs when repainting components
Description

Name: icR10030			Date: 05/30/2002


The jck1.4 test api/java_awt/interactive/LWComponentTests.html#LWComponentTests fails in Windows. 
After the "Hide lightweight component" button pressed, 
the lightweight component is not redrawn properly.
The bug is not reproducible in merlin and hopper-b11.

Filed By       : J2SE-SQA [###@###.###
JDK            : jdk1.4.1-b13, jre1.4.1-b13, jdk1.4.1-b12, jre1.4.1-b12
JCK            : JCK1.4-b17
Platform[s]    : Windows ME, Windows NT 4.0, Windows XP
switch/Mode    : -client -Xmixed, plugin for Netscape and Internet Explorer
JCK test owner : http://javaweb.eng/jck/usr/owners.jto
Failing Test   : api/java_awt/interactive/LWComponentTests.html#LWComponentTests

Test source location:
=====================
/net/jdk/export/disk8/local.java/jck1.4/JCK-runtime-14/tests/api/java_awt/interactive/LWComponentTests.java

jtr file location:
==================
/net/jtgb4u4c.eng/export/sail15/results/hopper/b13/jck14/win32/winnt4.0plugin_ie5.5_linux-20/workDir/api-interactive/java_awt/interactive/LWComponentTests_LWComponentTests.jtr

How to reproduce:
=================
--------Script START---------------------
#!/bin/sh

JCK="d:/jck1.4/JCK-runtime-14"
CLASSPATH="${JCK}/classes;${JCK}/javatest.jar"
JDK=e:/jdk1.4.1
PATH=${JCK}/lib

$JDK/bin/java -showversion -Xfuture 	-cp $CLASSPATH         -Djava.security.policy=$JCK/lib/jck.policy         -Djava.security.auth.policy=$JCK/lib/java.auth.policy         -Djava.security.auth.login.config=$JCK/lib/java.login.config         javasoft.sqe.tests.api.java.awt.interactive.LWComponent.LWComponentTests 		-TestCaseID ALL
--------Script END----------------------

Test output:
============
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b13)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b13, mixed mode)

LWComponentTest0001: Failed. A lightweight component cannot be resized, moved, hidden or shown.
STATUS:Failed.tests: 1; failed: 1; first test case failure: LWComponentTest0001

Specific Machine Info:
======================
Hostname: linux-21
Os: Windows XP


======================================================================

I attached another, simpler test case that does not involve lw/hw issues
called GdiLockTest.  This test runs in a loop, drawing a string into the
Component with and without a user clip set.  The effect of this should be
to make the text blink on and off every half second (off when the clip is
enabled because the drawString() operation is outside the clip boundaries).
When the bug is present, the text never blinks. 
###@###.### 2002-06-04
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper-rc FIXED IN: hopper-rc INTEGRATED IN: hopper-rc VERIFIED IN: hopper-rc
14-06-2004
WORK AROUND In the interim until the fix gets putback into hopper, a workaround is to disable part of the cursor flicker fix (which uses GDI for onscreen pixel manipulation) by using the command-line switch: -Dsun.java2d.ddlock=true ###@###.### 2002-06-06
06-06-2002
EVALUATION Commit to fix in Hopper (JCK) ###@###.### 2002-05-30 According to the Description, this bug is not reproducible in hopper build 11, but it is reproducible in build 12 and 13. The only AWT putbacks into build 12 were for 4627627 and 4668996. ###@###.### 2002-05-30 No, I'm wrong: there were other AWT fixes in build 12. See Comments for a list. ###@###.### 2002-05-30 This bug is due to the cursor flicker fix (4409306) that went into b12. On win2k and XP, we now avoid using ddraw entirely for operations that deal with the screen. Instead, we use a GDI bitmap to perform our rendering operations (such as drawing text) and then copy that buffer onto the screen. This regression test uncovers a bug in this approach: we do not detect the situation where a rendering operation did not occur as expected and we go ahead and copy the bitmap to the screen anyway. In this case, we get ready to do a rendering operation and then detect that the text we want to draw (which is the text in the Container) does not intersect the rectangle that we wanted to lock. Since there is no intersection, we simply unlock the destination and continue. But this unlocking process now involves copying the scratch buffer to the screen, so we end up copying outdated/incorrect data onto the screen. The fix is to note the failure case when we do not actually perform any rendering operation during the screen lock/unlock sequence and avoid copying the buffer to the screen in that situation. This can be done by noting whether we actually receive a call to GetRasInfo between the call to Lock and Unlock; if there is no call to GetRasInfo, then we should not copy the buffer in the Unlock call because there was no rendering to copy. ###@###.### 2002-06-04 The new test case attached to this bug (GdiLockTest) shows the bug very clearly. During the times when the text should not appear, it is written to the screen. This is because we are not doing the rendering of the text to the GDI bitmap, but we are copying that bitmap to the screen anyway; when we do this, that buffer contains the text that we had written to the buffer when the string _was_ supposed to be visible. The net effect is that the text never disappears because we always copy the text-filled buffer to the window. ###@###.### 2002-06-04
04-06-2002