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

Reply via email to