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
|
Java
