Having been down this rat hole once or twice for my apps, I can only tell you 
my understanding. Which may or may not have any bearing on reality:

If you select a “non-native" display mode, then the display/display driver are 
responsible for the conversion from the selected resolution to native 
resolution. This will be invisible to your app. In other words, at the NSView 
level, the backing store (if it’s a pixel backing store) will be at selected 
resolution, not native resolution. This has nothing (or at least not much) to 
do with retina mode, which really only refers to the mapping between points and 
pixels. That is visible to your app. A pixel level backing store for a retina 
display will always be at full res.

You may possibly be able to “see” native rather than “selected resolution” with 
e.g., an OpenGL view or similar - I don’t know. I gave up trying to use the low 
level interface years ago. But I don’t think you can with the conventional 
Cocoa display stack you are currently using.

Sandy

> On Dec 19, 2016, at 12:52 AM, Kurt Bigler <kkbli...@breathsense.com> wrote:
> 
> On 12/18/16 12:33:53 PM, Ken Thomases wrote:
>> On Dec 18, 2016, at 2:15 AM, Kurt Bigler <kkbli...@breathsense.com> wrote:
>>> 
>>> But if in Displays I set the resolution to 1920x1200 "More Space", then I 
>>> can't get the backing store to match the 2880x1800 physical display 
>>> resolution.  I need my NSView's backing store scale factor to be 1.5, but 
>>> the doc says this is impossible.  As things are currently coded, my image 
>>> gets smaller, and I get weird artifacts in high-contrast high-resolution 
>>> information.  Presumably the backing store resolution is 3840x2400.
>> 
>> What exactly did you try?  For example, what size did you make your image 
>> for this scenario?  How did you draw it?  Did you try drawing a 2880x1800 
>> pixel image to a 1920x1200 point rectangle (or some appropriate fraction of 
>> those sizes) using CGContextDrawImage()?
> 
> I tried various possibilities at one time or another, and eventually 
> discovered as a result that it was a complete mess if the destination was not 
> targeted with awareness of the scale factor of the backing layer, so that the 
> rectangle  that would result in the backing layer (not explicit in my code) 
> matches 1:1 with the bitmap I'm drawing using CGContextDrawImage.
> 
> So basically in the retina case that works, my source rectangle is 2x, and 
> that is the basis of calculating the pixels for the CGImage.  But the 
> destination rectangle for CGContextDrawImage is in view coordinates which are 
> 1x, yet of course behind the scenes that destination becomes 2x for the 
> actual image copy to the backing store which is at 2x.  So a 100x100 view 
> area gets a 200x200 image.
> 
> Still the essentials as I see it are the fact that it works perfectly when 
> the backing store resolution and scale factor match the device, and that the 
> OS seems to interfere with the possibility of that matching except when the 
> ratio is 2 to 1.  And the next best (next-least-distorted) result when the 
> backing store doesn't match the device is still to have the source image 
> match the backing store.
> 
> So I'm back to hoping it is a simple question, i.e. for Apple.
> 
>> You mention CALayer, albeit mostly in the context of something you don't 
>> know much about.  Is your view layer-backed?
> 
> You tell me.  :)   No I didn't do anything to try to arrange that.  But 
> clearly there is some default backing store.  What is it?  Some doc says 
> there is a default CALayer that is in some way trivial but it is not 
> explained in what situation that default applies.
> 
> Does it make any difference if you make it so by setting wantsLayer (either 
> in code or in IB)?
> 
> I don't want that off-hand because it gets me into the things I don't yet 
> understand.  :)   I'm willing to do it if it is necessary but don't get 
> excited about it if I can just tell the backing layer to have the desired 
> resolution although the docs claim it doesn't, and the question is whether 
> that means can't.
> 
> The mere name "Core Animation" suggests things I have no interest in since I 
> have only a static image, yet of course names can be misleading.  It's just 
> that the doc constantly rubs in that Core Animation is for animation, and the 
> other layer example I saw was for a video layer.
> 
> So I'm still thinking it ought to be a simple question and hope first for the 
> simple answer even if it is that I must create my own backing layer, and even 
> that CALayer is appropriate when I have no need for animation.  If that's 
> what's needed that's what I do, and I can learn all about it in the coming 
> weeks, but want to hear clearly that I need to get into that particular 
> wrestle to solve the simple problem.
> 
>> Regards,
>> Ken
> 
> _______________________________________________
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mcguffogl%40gmail.com
> 
> This email sent to mcguff...@gmail.com


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to