JDK-4711587 : REGRESSION in 1.4.1-beta: Drag JInternalFrame in JDesktopPane.OUTLINE_DRAG_MODE
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-07-08
  • Updated: 2002-10-02
  • Resolved: 2002-10-02
Related Reports
Duplicate :  
JDK-4665237 - REGRESSION: JInternalFrame outline dragging is very slow to respond
Relates :  
JDK-4409306 - W2K: mouse and menu flicker occurs when repainting components
Description

Name: jk109818			Date: 07/08/2002


FULL PRODUCT VERSION :
JDK1.4.1 beta

FULL OPERATING SYSTEM VERSION :
Windows 2000

A DESCRIPTION OF THE PROBLEM :

When dragging JInternalFrame in DesktopPane.OUTLINE_DRAG_MODE,
the JInternalFrame moves slowly and flushes quickly.


REGRESSION.  Last worked in version 1.4.0


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

C:\j2sdk1.4.1\demo\jfc\Metalworks\Metalworks.jar

---------- END SOURCE ----------

Release Regression From : 1.4
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 158983) 
======================================================================
Comments
WORK AROUND In 1.4.1 (on Windows only), using the -Dsun.java2d.ddlock=true flag should help get performance back to 1.4.0 speeds, but this could cause cursor/menu flickering on Windows 2000 and XP. ###@###.### 2002-10-01
01-10-2002
EVALUATION This bug seems very similar to 4665237. That bug was reported against linux, but has been noticed under other platforms. Under linux this problem seemed related to the setXORMode method. Looking to see if this is the same for windows. ###@###.### 2002-07-08 Talked with the 2D group. Transferring ownership to them. ###@###.### 2002-07-11 Some comments from Dmitri: check out the comment for this bug: http://andorra1.sfbay:8080/cgi-bin/ws.exe/bugtraq/jdk/bug.hts?bugid_value=4686738#jdccomments Performance regression on windows is much more noticeable in 1.4. On my Win2K machine: 1.3.1 32ms 1.4 375ms 1.4.1 1500ms <<<-- this is BAD. I get the same level of performance in 1.4 with disabled ddraw ###@###.### 2002-07-11 This bug is essentially the Windows-only counterpart to the more general bug 4665237. The reason XOR-to-screen performance regressed so badly from 1.4.0 to 1.4.1 is due to the cursor flicker fix (4409306). In 1.4.1 we use the "lock by DIB" mechanism, which means we first lock a scratch bitmap (DIB), use our software XOR loops to render to the DIB, and then copy the DIB to the screen. This helps minimize cursor/menu flicker, but at the expense of XOR mode rendering performance. The fact that we don't use platform (GDI) XOR rendering in 1.4.0 and 1.4.1 causes us to use our software loops to render to the screen. This meant lower performance in 1.4.0 because XOR is a read/modify/write operation, and our software loops had to interact directly with the screen pixels. And then in 1.4.1, we're even slower due to the lock-by-DIB mechanism. (See workaround section.) In any case, I'm going to close this bug as a duplicate of 4665237 because the fix for that bug will essentially fix the root cause of this bug. When that bug is fixed (in mantis), we will use GDI for XOR mode operations to the screen, which will avoid the lock-by-DIB penalty altogether. At that point we should see performance equal to or better than 1.3.1 performance. ###@###.### 2002-10-01
01-10-2002