In looking through the ToolkitImage code some more it occurs to me that it was
already designed (moreso in a previous life) to hold onto multiple
representations of the image anyway. In a prior life in 1.0 and 1.1 it held
separate ImageRepresentation objects for each size it was scaled to (via
drawImage(w,h)), but that was simplified to a single ImageRep when we converted
to Java2D and started doing scaling on the fly for all drawImage() operations.
Still, the concept of an alternate resolution version of the image is probably
more in line with the ImageRepresentation object within the ToolkitImage than
in having multiple ToolkitImage objects and a wrapper for them.
This would also deal more naturally with the ImageObserver issue since there
really would be only one Image and SG2D would not deal with the
sub-representations, it would be dealt with in the DrawImage pipeline code when
it queries the ToolkitImage for the ImageRepresentation object.
In the end, I think that design would be simpler overall, would it be possible
to shift those gears for this fix? If not, we should consider it for a
near-term future cleanup task perhaps...
...jim
On 11/19/2013 7:58 PM, Jim Graham wrote:
Based on the information below, I have the following suggestions...
We should probably allow asynchronous loading of the scaled resolution
variants. This is a minor variation of what the ImageObserver was originally
designed for, but technically might violate some developer's expectations if
they have only dealt with a post-Java2D version of Java. Some education might
be helpful here.
The wording on drawImage(dxy12, sxy12) should probably be reworded to indicate
that asynchronous scaling would not happen, but alternate versions of the image
may be accessed.
In all cases, if the version of the image that we would ideally want to show
hasn't been loaded, but the standard version has (or if @2x was loaded, but we
want the regular version too?) then we should probably go with the version that
was loaded, but still trigger the loading of the alternate version and notify
their Observer as it is loaded.
I also examined the places in the code where we notify the ImageObserver. A
search for the observer method should show all places we call it, but the
primary ones look like they are fairly few places. If we tag the resolution
variant images with the composite image from which they came, then we can have
those few places do something like:
Image obsimg = (img instanceof SunToolkitImage) ? (() img).getObservedImage() :
img;
I think in most cases the img is already known to be our internal SunToolkit
image and so we don't even need to check instanceof...
...jim
On 11/19/2013 7:01 PM, Jim Graham wrote:
I did some more reading about the various ways in which the ImageObserver is
used and noticed the following points, some of which may be to our advantage.
Many of the drawImage() calls mention that they will notify the observer as the image is
"scaled or converted for the output device". I believe in the world before 2D,
we would often have to load or convert the image asynchronously for various changes in
the output. When we created the 2D interface and added some on-the-fly image scaling
code, we mentioned that scaling was no longer asynchronous, but technically the API is
still designed for asynchronous operations when the rendering parameters change.
However, the drawImage() call that takes 8 parameters dxy12, sxy12 -
specifically includes the words:
* This method always uses the unscaled version of the image
* to render the scaled rectangle and performs the required
* scaling on the fly. It does not use a cached, scaled version
* of the image for this operation. Scaling of the image from source
* to destination is performed such that the first coordinate
* of the source rectangle is mapped to the first coordinate of
* the destination rectangle, and the second source coordinate is
* mapped to the second destination coordinate. The subimage is
* scaled and flipped as needed to preserve those mappings.
public abstract boolean drawImage(Image img,
int dx1, int dy1, int dx2, int dy2,
int sx1, int sy1, int sx2, int sy2,
ImageObserver observer);
which basically, at the time it was created in 1.1, was an opt "out" of the
asynchronous operations that might happen when you scaled an image with drawImage(xywh).
As worded, this would suggest that this method does not use the @2x version and always
uses the default resolution version, but those words were not put there for this
particular intent, they were put there to indicate that we weren't going to do an
off-line scaling of the pixels which sometimes happened in 1.0.x and possibly 1.1 (for
the other calls that predated 1.1 until Java2D).
I also found the Component.prepareImage() and Component.checkImage() methods
which also take an ImageObserver. Those methods imply that they will possibly
start the process and return information on a particular version of an image
appropriate for the current output device. There is even a prepareImage(w,h)
method that gets an image ready to render at the indicated size. Given that
these methods are on component, it probably makes sense to have that code look
up which representation would be used for those indicated dimensions on the
indicated output device that the Component is displayed on.
...jim
