JDK-4268962 : Use of intermediate buffers slows scaled drawImage calls on screen
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.2.0,1.2.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_95
  • CPU: generic,x86
  • Submitted: 1999-09-03
  • Updated: 2013-11-01
  • Resolved: 2001-07-23
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.0 beta2Fixed
Related Reports
Duplicate :  
JDK-4185726 - JDK 1.2 drawImage very slow compared to JDK 1.1.7.
Description
Drawing images to the screen at anything other than 1:1 scaling is much
slower in JDK 1.2.  The performance differential is different at different
screen depths - on one card the difference was much greater at 16-bits than
at 32-bit TrueColor.

The difference is more noticeable on Windows than Solaris.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta merlin-beta2 FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2
14-06-2004
EVALUATION The current interface to the MediaLib image scaling code uses a different interface to the pixels than our blit loops. It will be easier to consolidate the scaling routines into the blitting engine when we redesign the interfaces for consistency. The new internal Graphics Primitive architecture will provide that facility, but will not be available until after Kestrel. jim.graham@Eng 1999-09-29 Note that this performance loss has little effect if any on the performance of printing scaled images. There are other problems affecting the printing of images much more seriously in JDK 1.2 and are being tracked under different bugs. The performance impact of drawing a scaled offscreen image (i.e. an image created using the createImage(w, h) factory method) suffers far more from the problems behind bug 4276423 (drawImage of offscreen image to screen much slower in JDK 1.2) than by the extra buffering indicated here. Some of the performance loss of scaled images has been improved for the 1.3 release, but there is still a significant impact from the intermediate buffers which can cause glitches due to garbage collection. The performance differential should now be between 20 and 40% for scaled images. jim.graham@Eng 1999-09-29 Note that this bug is not a replacement for 4185726. Many of the performance problems that were detailed in bug 4185726 have been fixed for the 1.3 release. The Plasma applet was affected by a number of problems, all but one of which was fixed for 1.3. This bug represents the sole remaining problem affecting that applet. For some platforms and configurations, the Plasma applet now runs faster on 1.3 than on 1.1, but the issue of the extra intermediate buffers used by the scaled drawImage variants still causes speed and garbage collection problems for that applet. This bug is also not representative of the concerns of many of the developers who were tracking 4185726. The problems mentioned in the JDC feedback for that bug varied quite a bit and many of those problems were also fixed for the 1.3 release under different bug ids. The remaining concerns have been collected under various bugids to isolate and categorize the problems that developers are having. A list of bug ids has been appended to bug 4185726. Developers should review that list to see if any of those bugs represent their concern and to find out if their problems have been or are being addressed. If their concerns are not covered by any of the bugs indicated in that bug report then their concerns are not known to the Java Software team and are not being tracked currently. Changing a JDC vote from bug 4185726 to this bug will not ensure that we are aware of or are addressing the problems that a developer is seeing. Only by reviewing the listed bugs and by submitting a new bug report if needed will we be sure of tracking all concerns. jim.graham@Eng 1999-09-29
29-09-1999