So, then, it sounds like on the Mac the "default heuristic" should be to
take the transform into account and choose @2x based on that. We don't
yet know if that matches the default Windows 8 heuristics, but we only
have 1 platform that has this enabled so far.
One last question (OK 2) for Mike - I want to be sure that we get the
algorithm right, you said "if the backing store would be the same size
or smaller than the @1x" which implies that the code in the fix "if (w
<= imgw && h <= imgh) regular : @2x" matches the heuristics in Cocoa?
(i.e. && and <= are the correct comparison and logic?)
And question #2, if they are running on a display with pixel scale of
1.0, does the @2x get chosen when they scale up? Or do the @2x media
only even get considered on pixel scaled displays?
Given that, I'd recommend:
- Add the DEFAULT setting for the SunHint which will basically say "do
as Mac does when on a Mac" (and eventually as Win8 does while on Win8,
etc.)
- the current fix has the choice in the macosx code, which is good
- the current API provides the scaled dimensions, which is good for the
mac code, but we may need to make more data available once we learn how
other platforms solve this problem
- we may want to beef up the hints later with "choose based on Screen"
vs "choose based on pixel size", but for now this API is sun.* private
so lets just leave it with ON/OFF/DEFAULT.
- Hopefully the answers to the above 2 questions for Mike won't be
surprising...
...jim
On 11/12/13 6:46 PM, Mike Swingler wrote:
The story is a little more complicated: NSImage always picks the "best" representation
based on the computed size of the backing pixel rect taking all graphics transforms into account.
For icons, which usually have dozens of representations, there isn't a single "@2x"
representation.
This means that by switching screens, an icon can flip from a cartoonish 16x16
rep to a photo-realistic 128x128 scaled down to 32x32 if those are the only
reps available. The multi-rep support in NSImage can also defer to a PDF
representation if available when it can't find an exact dimension and bit-depth
match for raster representations.
This does mean that an icon with 12 or so representations will visually glitch
when smooth scaled as bits of detail come and go...but in the general case,
most images tend to only have 2 reps and developers don't animate between them.
So to be explicit: no, NSImage Cocoa drawing will not choose the @2x version if
the transform causes the rect in the pixel backing store to be the same size or
smaller than the @1x.
I'll privately send along a little app that demonstrates this.
Regards,
Mike Swingler
Apple Inc.
On Nov 12, 2013, at 5:52 PM, Jim Graham <james.gra...@oracle.com> wrote:
Hi Mike,
Just to confirm and be explicit, the Mac will choose the @2x version of an
image if that call returns 2.0 even if the user is rendering with a transform
that scales by .001?
...jim
On 11/12/2013 5:48 PM, Mike Swingler wrote:
On Nov 12, 2013, at 11:43 AM, Jim Graham <james.gra...@oracle.com> wrote:
- It looks like the transform is used in SG2D to decide if the hiDPI image should be
used. I'm not familiar with the Mac's native use of @2x, but I thought that they hinged
the decision off of the "retina scale" of the display, not off of the current
transform. That way, if you scale down an icon it doesn't change its look when it
reaches .5x scale (or .75x depending on the cutoff). Personally, I think it is better to
not use the transform to keep animations smooth, but I'm not sure what Apple did.
The -[NSWindow backingScaleFactor] is the basic primitive that other forms of
coordinate translation key off of. Keep in mind that this value will
dynamically change as the window moves from display to display.
Regards,
Mike Swingler
Apple Inc.
