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

[Jim Graham]

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

			...jim

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