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

[Jim Graham]

On 11/13/13 4:33 AM, Sergey Bylokhov wrote:
> On 12.11.2013 23:43, Jim Graham wrote:
>> - The logic in using the transform is also a bit murky.  I think if
>> you set the scale on a retina display to exactly 1/2 it would use the
>> HiDPI version even though the scale was 1:1.  Since I support not
>> examining the transform there, I'm going to present this as another
>> reason why we should just base it on devScale, but the logic could be
>> fixed if we really plan to use the transform here.
> It also allow to the user to use a transform and a hint and force the
> images to draw the scaled version even to the BufferedImage fo ex. Which
> can be useful in case of sequential drawing of BI-> BI->retina.

I think you misunderstood me here.  I'm not saying anything about the 
BI->BI->retina case.  I'm saying that even on pure retina your logic 
chooses the wrong scale because of mistakes made in examining the 
transform state type.

If devScale is 2, but the transform is a scale then the scales used to 
compute the resolution image will be based solely on the transform.  If 
devScale is 2, but the transform is identity, then the scales used to 
compute the resolution image should be 1.0 because that is the actual 
scale being applied to the image, but the logic will use 2 (i.e. the 
devScale) instead because of bad handling of the transformState.

Also, in the case of TRANSFORM_GENERIC just the devScale is used even if 
they scale it down to .001.

You probably need to only use the transform if you are going to use it 
at all and you need to use it for all transformState values (there may 
be optimizations based on the transformState, but the most complete 
transform type should not fall through to a default, neither should the 
translate-only states).

>> - Has any thought been given to my comments about MediaTracker and
>> image observer states for multi-res images?  I don't see any attempt
>> here to preload the @2x image.  The problem would probably only be
>> seen on multi-headed systems where one display is retina and one is
>> not - you would find the images suddenly reloading when you move the
>> window to the other screen and the application might not expect that
>> to happen.  Which image is the Observer registered on?  Since the
>> image is handed to the Observer, will an application be surprised when
>> their observer gets a handle to an image they've never seen?  Is it an
>> issue if one of the "alternate resolution variant" images leaks into
>> an application's "hands" via the observer callbacks?
> 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

			...jim