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