JDK-4228939 : New pipeline architecture needed to reduce overhead of common operations
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.2.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic,x86
  • Submitted: 1999-04-12
  • Updated: 2013-11-01
  • Resolved: 2000-11-21
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 Availabitlity Release.

To download the current JDK release, click here.
1.4.0 betaFixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Many common operations performed on a Graphics object will interrupt
the rendering process by causing rendering pipeline invalidation and
the de-caching of important rendering information.  While such validation
may be necessary in some situations, the validation steps are executed
very conservatively in the 1.2 implementations.

For example, the rendering data will be invalidated when the color is
changed from one opaque color to another, when a graphics object is
cloned using the create() method, when a simple integer coordinate
translation is requested, and many other operations which do not
fundamentally change the nature of the rendering algorithms needed
to respond to the various rendering requests.

Since Swing hierarchies typically rely heavily on using the create(),
setColor(), translate(), and clip() methods this can waste a lot of
time during application repaints while the many graphics objects have
their rendering data re-created over and over again during pipeline
invalidations and subsequent validations.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin merlin-beta FIXED IN: merlin-beta INTEGRATED IN: merlin-beta

PUBLIC COMMENTS Common graphics operations impact rendering performance more than necessary. A new pipeline architecture is needed to reduce this overhead and to allow for greater hardware acceleration.

EVALUATION There are a number of changes that can be made to reduce the overhead of invalidating the pipelines: - Cache more data in a centrally accessible location hanging off of the Grahpics object that is shared between rendering operator objects so that they are not customized for a particular Graphics object. - Move all rendering-attribute-specific data out of the actual rendering operator objects themselves so that they do not need to be recreated every time the attributes change. - Use better heuristics to determine when an attribute change will result in actual change in the implementation of the rendering objects. jim.graham@Eng 1999-04-12 A major rearchitecture of the 2D graphics implementation is well underway. The following issues have already been addressed: - Color information is stored centrally in the common internal Graphics2D class which is handed to all rendering primitives - setColor no longer invalidates the pipeline unless the new color is different in type than the old paint (i.e. changing from a Paint object to a color, or from translucent to opaque). - clipRect no longer invalidates the pipeline unless the nature of the clipping has changed (i.e. from arbitrary shape to a simple rectangle or vice versa. - the clip information is now stored in a central location in the common internal Graphics2D class where all primitives can access it on the fly - All output destinations have been consolidated via a new access class (SurfaceData) that abstracts how the pixels are stored so that the same primitives can access the screen just as easily as they access a BufferedImage - All rendering primitives which were instantiated for specific color or clip data were deleted now that the data is stored in a central location. In addition, rendering primitives that were specific to a particular destination type were deleted in favor of primitives that use the new SurfaceData abstration. This has drastically reduced the number of classes in the implementation. - The rendering primitive lookup routines were modified to do a binary search on a sorted list of primitives to reduce the lookup time. - Caching of rendering primitives was formalized and centralized to increase the sharing of the caches and to reduce the number of times a full lookup is needed. - All subclasses of the primary internal Graphics2D object were deleted in favor of better delegation and logic in the main class - All native information was removed from the main Graphics2D object and moved into delegate objects that are much longer lived so that Graphics objects no longer need to be finalized. This greatly reduces the time spent garbage collecting. - The logic of using platform specific graphics pipelines was formalized and simplified so that new implementations could be developed and optimized without impacting core 2D code. The new pipelines were also architected to share platform graphics handles to reduce the system resource usage. - A better mechanism for instantiating "workaround" primitives to fill in the gaps when no existing specific primitive is available to do the exact operation requested. The new mechanism shares code better and reduces the amount of code devoted to doing generic versions of specific operations. - A new glyph cache access object was created to allow more pipelines to use the native glyph cache for rendering information. This means that text drawing code for complex, custom, and unusual sets of attributes no longer has to back off to rendering text from outlines resulting in faster, more consistent, and more readable text in a wider variety of rendering conditions. The work continues to improve all areas of the 2D architecture with an eye towards reducing the number of classes, increasing the coverage of the optimized loops, increasing the reusability (and thus consistency) of our internal rendering mechanisms, and reducing the time needed to handle common operations. jim.graham@Eng 2000-02-07