Further investigation on the second problem listed in the bug 4482157: moving a window containing an image causes the image to "lag" behind the window movement. When the window stops, the image catches up.

Based on the feedback of Jerry Evens:

Problems 1 and 3 are due to the same problems that caused 4482141. I am closing this bug as a duplicate. However, problem 2 seems to be a real bug, but not in drawRenderedImage. If I turn drawRenderedImage into a no-op, the lag in dragging around the magnifier window is still apparent. This should be investigated further and a new bug files against

In the second time investigation, the following were found:

1. The lagging of the magnifier component: Comment the drawRenderedImage in
Magnifier and drag the magnifier to move around. Sometimes, the magnifier lags
behind the mouse movement. This is because full GC is triggered in jdk 1.4. Each
full GC takes about 0.3-0.4 seconds. In this period, the modifier stops at one
place and starts moving until full GC finishes. Using jdk 1.3, only GC but no
full GC is triggered when the magnifier is moved around. Please see the attached
gc time table (gc_jdk14 and gc_jdk13).

2. The image display in the magnifier component lags behind the window movement.
To reproduce this one, click on the corner of the magnifier component. When clicked at the upper left corner, the magnified image is displayed correctly (or almost, there were blue lines at the right and bottom side); when clicked at the lower right corner, only the first quadrant was filled with the magnified image and the other three quadrants were filled with blue; when clicked the other two corners, only left or upper half was filled with the magnified image. Think this is fixed in 4482157 (Java 2D group, please verify this assertion).

Also tested on NT with jdk 1.4 builf 72, similar behavior was found. Please see the attached new file gc_nt which contains all the gc data for both jdk 1.4 build 72 and jdk 1.3.

Another interesting problem is that the memory footprint on NT is much smaller than on solaris. The computers have tha same ram size: 256M.

qinghuai.gao@eng 2001-07-25

Further investigation shows that:

1. Using the java command line option to tune the gc helps a little to delay the full gc triggering. For example, when inc gc is set, a full gc is triggered after every 6 gc/incgc. Other options also delay the full gc but sometime when full gc is triggered it spends more time (1-2 seconds or event longer comparing the 0.3/0.4 second as listed in the attached file gc_jdk14).

Logging about 70 seconds on this application shows that about 15 seconds are used in gc for jdk 1.4.

2. For jdk 1.4, between 2 gc, about 12 re-paintings are executed. As a result, more space is allocated and needed to be collected. However, each gc only collected memory as little as about 1M (as listed in gc_jdk14). So, a full gc has to be triggerred. Please find the reason why the regular gc is so inefficient in jdk 1.4.

3. For jdk 1.3, between 2 gc, about 6 re-paintings are excuted. At each gc, about 6-10M are collected (more efficient comaparing the jdk 1.4). This do prevents the full gc to be triggerred and makes the interaction more smooth.

qinghuai.gao@eng 2001-07-27

More detailed investigation is reported below:

Run this jai tutorial with jdk 1.3 and jdk 1.4 build-73. Interactively move the mouse 1 minute. Count the re-painting number and gc number.

Using jdk 1.3, in one minute, re-painting is executed 944 times, gc 314 times (no full gc), total gc time 0.88 second.

Using jdk 1.4 build-73, in one minute, re-painting is executed 664 times, gc 127 times, total gc time 12.12 seconds.

Because jdk 1.4 use 20% of the time on gc, so we normalize the count number using 0.8. As a result, in one minute, jdk 1.4 executes re-painting 664/0.8 = 830 times, gc 127/0.8 = 159 times.

In summary, (1) jdk 1.3 triggers 2 times gc as jdk 1.4 does. (2) jdk 1.4 uses a long cumulative time on gc than jdk 1.3 with the same memory parameters. (3) Also find the regular gc in jdk 1.4 is less efficient than jdk 1.3 as described above. (4) The number of re-painting between 2 gc varies from time to time. But generally, twice of the re-painting is executed when using jdk 1.4 comapring using jdk 1.3. This is consistent with the statement (1) above.

qinghuai.gao@eng 2001-07-27