Name: jk109818			Date: 10/15/2002


FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows XP [version 5.1.2600]



EXTRA RELEVANT SYSTEM CONFIGURATION :
800x600 display or more

Note: this case affects some TFT displays on notebooks,
using a Microsoft Certified DirectX driver such as NeoMagic
MagicGraph 128ZV/ZV+/XD on HP Omnibook, and many other TFT
display controlers. There is no such scroll problem in any
other DirectX application: this just affects Java, so I
figure out that some documented Direct2D APIs are not used
properly, and direct on-screen bitblitter operations are
used with out of range values (notably the maximum
scrollable width).



A DESCRIPTION OF THE PROBLEM :
Active scrolling in scrollable areas (where this is done by
direct on-screen bitbliter operation, instead of refreshing
all the area) does not work properly when the scrollable
area is wider than 682px.

It seems that bit-blitter operations (Direct2D?) are not
synchronized correctly, when this operation must be
decomposed in bands on some displays. Java2D does not honor
some Direct2D properties of the display, such as the
maximum width of the onscreen move.

The result is that scrolling in any any AWT or Swing
component (JList, JTable, JTextArea, ...) which is larger
than 682px does not work properly and using the scrollbar
renders a scrolled text completely unreadable, with some
parts that are redrawn, some parts are scrolled, and some
parts of the area is left unchanged. These parts are
rectangular, with some constant width offsets, but the
vertical height of the affected rectangles is unpredictable.

This 682 pixels width limit bug occurs in 24 bit color
mode, but not on 8-bit or 16-bit color mode. So this better
indicates a limit to the byte size of a raster line. The
640 pixels limit is then 1920 bytes (probably the exact
size is 2KB, and the exact pixel count in 24 bit mode is
682 pixels. One can set its screen display size to 1024x768
in 16-bit mode, and you will not experiment this problem.

However if you use the 1280x1024 resolution in 16-bit mode,
you can have scrollable areas larger than 1024 pixels. In
this case too, you will have garbled display for any
scrollable area larger than 1024 pixels.

This also affected Java 1.4 and Java 1.3.1.

Note: this case affects some TFT displays on notebooks,
using a Microsoft Certified DirectX driver such as NeoMagic
MagicGraph 128ZV/ZV+/XD on HP Omnibook, and many other TFT
display controlers. There is no such scroll problem in any
other DirectX application: this just affects Java, so I
figure out that some documented Direct2D APIs are not used
properly, and direct on-screen bitblitter operations are
used with out of range values (notably the maximum
scrollable width).

This may be due to a limit to the size of the intermediate
buffers needed to compute a raster line, or even to a bug
in the way Java computes rectangles on which to perform a
bit-blit operation.

It's possible also that Java does not wait for the
effective end of Direct2D on-screen bitblitter operation
before performing the next operation.

This affects nearly ALL Java applications that use Swing or
Java, to display scrollable areas such as an JHTMLEditor, a
JTextArea, a JList, a JTable, ...

This bug never affects static components (JPanel, JMenu,
JButton and so on), unless they are included in a large
scrollable area.

This affects any Look&Feel or Skin...

This affects the SwingSet2App (in JavaWebStart 1.2) as
well: notably the "Source Code" window, which is also
nearly unreadable because of the (much too small) italic
font used. It also affects the rendering of the JEditorPane
HTML demo (garbled display occurs on scroll on any part of
the HTML page: the image and the HTML text as well), the
JTable demo (people, favorite movie, favorite food images),
the Tree demo (when some nodes in the tree are exapanded so
that vertical scrolling becomes possible).

(strange!) This does not directly affects the demo of the
Scroll Pane (which just displays a large scrollable image
with color pens): I can scroll it, I see the rectangle
decomposition (with some flickering effects on their
limits), but the result is not garbled when I stop
scrolling: may be Java honors multiple "WM_REDRAW" message
from Windows, and Windows and its driver carefully computes
the appropriate subrectangles that must be drawn
individually and not aggregated in a single wide bitblitter
operation.

This bug never occurs on any 2D game using DirectX for
Windows (out of the Java environment). This is a pure Java
bug for screen-to-screen operations (typically: for
scrolling). I feel it strange that it does not affect
internal JFrames when moving them around in a frame
container: would Java not used Direct2D but instead use
refreshes operations when moving windows around (memory to
screen bit-blitter operations).

This does not affect the internal frame demo when scrolling
the small images vertically in a large internal JFrame.
This bug cannot be reproduced with modern 3D accelerators
cards found on desktops (which have more than 2MB of
display RAM), but you can reproduce it on many notebooks,
and with some old 2D-only PCI accelerators for desktops
(including some models from nVidia, Trident, Orchid, ...).

Did you forget to honor the maximum bytesize of raster
lines for Direct2D bitblitter operations?

Note: this bug did not exist in older versions of Java
(don't know which exactly, but this may have been Java
1.3.0): this may be due to a new use of some Direct2D
operations, and assumptions about DirectX display
capabilities... With Java 1.4 this bug is reproduced much
more easily than with previous versions (may be because
previous versions were not using Direct2D directly within
AWT but only on some components). The bug would then be
somewhere in AWT or Java2D...


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Use a notebook with a simple 2D accelerator and using
DRAM separated from the internal RAM (this affects for
example the HP Omnibook 2100 and previous Pentium II models)

2. Set your display to 800x600 in 24-bit color mode.

3. Start JavaWebStart 1.2

4. Run SwingSet2 App. Enlarge it to full screen (or at
least to full width, and reduce the vertical height of the
applet to no more than about 600 pixels.

5. Click on the JEditorPane HTML demo.

6. Drag slowly with the mouse the vertical scrollbar.
Observe that the display scrolls only on the left, top or
bottom parts of the scrollable area, but the central part
is not refreshed correctly.

EXPECTED VERSUS ACTUAL BEHAVIOR :
The whole scrollable area should scroll, not only some
small rectangular parts of the scrolled zone. The display
should remain coherent.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
None. Just use the J2SE run-time and Java Web Start to reproduce the bug.
You probably must test it on some old displays, or on Pentium II notebooks (2
years old).
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
NONE. Except reducing the window width, if possible in the
Java application, to limit the display width of the
scrollable area.

The impact is that any user with such notebooks would think
that Java is bogous, or its applications as well, if they
can't scroll in a simple large text area. Also, typical
machines used by developers or for business applications
don't have a good 3D accelerator, but just a basic 2D
display card, with no complicated drivers: this may affect
a lot of users working on 1024x768 displays in 24-bit color
mode. Also, on notebooks, one cannot change the display
card...
(Review ID: 165423) 
======================================================================