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.Many common operations performed on a Graphics  customer  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  customer  is
cloned using the create() method, when a simple integer coordinate
translation is requested, and many other operations which do not
fundamentally change the  customer  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.

N/A

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.

  xxxxx@xxxxx   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.

  xxxxx@xxxxx   2000-02-07