On 11/13/13 11:44 AM, Sergey Bylokhov wrote:
On 13.11.2013 23:25, Sergey Bylokhov 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.
No I understood. But a transform of the sg2d already include devScale.
This part of the fix was changed from version to version. We could use
devScale only, or a transform if it is scaled, or an any transform. If
nobody objects, we could use any type of transform.
My point about BI1-BI2-retina is that the user cannot control
devScale, and so cannot force BI1 to use scaled version. But if we
take into account current transform of the SG2D, then user can control
that via transform and hint.
I just realize that hint is not necessary now and can be skip it,
because we use instanceof anyway(img instanceof MultiResolutionImage).
I'm not sure what hint you are referring to under which conditions?
If you are referring to SunHint and its new values, I agree that it is
mostly redundant now to get the default behavior that developers are
looking for. I thought it was being created to provide a non-public API
for being able to turn off the behavior? (i.e. a "use at your own risk
since this is in sun.*" API)
I think we will support @2x images just fine without it, though...
...jim
