<AWT Dev> [OpenJDK 2D-Dev] [8] Review request for 8011059 [macosx] Make JDK demos look perfect on retina displays

Jim Graham james.graham at oracle.com
Wed Nov 13 14:08:40 PST 2013

If, by bypass, you mean that we would simply punt, then I think we need 
to test the behavior with MediaTracker minimally.  I get the impression 
that MT will not work with these new wrappers for a couple of reasons 
(needing to track the indicated image instance, and it would only track 
the original size so that the first render to a retina scale would 
fail).  As to the other issues, I worry about them, but I have no direct 
data of how much headache they will cause our developers...


On 11/13/13 1:55 PM, Sergey Bylokhov wrote:
> Hello, Jim.
> On 13.11.2013 22:49, Jim Graham wrote:
>> That's could be a problem. Is it possible to wrap imageObserver, which
>>> was passed to the drawImage, and replace one image to another in the
>>> WrapperImageObserver.imageUpdate()?
>> It's possible - the things to watch out for:
>> - they could hand the same IO in for multiple drawImage calls to
>> multiple images
>> - they could hand the same IO in repeatedly for the same image while
>> it is loading if the loading takes a while or the image is animated;
>> you don't want to necessarily create an infinite number of wrappers
>> for the same observer and register them all with the image loading
>> mechanism
>> - the image that you report to them should probably be the original
>> image, not the resolution-specific underlying images
>> - we need to deal with making sure that the information flowing to the
>> IO does not report complete until all resolution variants that we plan
>> to load are done
>> - given Mike's answer to my previous questions, it looks like @2x is
>> not a retina-specific issue, all images do that even non non-retina
>> apparently so maybe we do want to load all variants up front?
>> - we don't want to pass ERROR conditions to the IO unless all
>> resolution variants are errored, we should silently swallow any ERROR
>> conditions for just some of the resolution variants and make do with
>> what we have
> Well, it is necessary to decide that it is simpler to bypass all these
> problems or to move them to the user. As ScalableToolkitImage
> implementation is trivial.
>>             ...jim

More information about the awt-dev mailing list