HiDPI retina issue with multi-screen overlay window and Core Animation

[William J. Cheeseman]

My Pointer Noodge application displays an animated image surrounding the mouse 
pointer using a layer-hosting multi-screen view: 
. I am having difficulty upgrading it to 
handle a mix of retina and non-retina displays. All help appreciated.

The specific problem is that the image surrounding the pointer appears highly 
pixellated when the pointer moves onto a HiDPI screen. I can see that the 
correct @2x image has been loaded into the layer's contents, and it appears at 
the correct size on the HiDPI screen, but it is pixellated.

My implementation creates a borderless transparent overlay window more or less 
on the model of Apple's FunkyOverlayWindow sample code. The overlay window 
encompasses all attached screens (which I suspect is the problem; see below). 
The overlay window's content view is a layer-hosting view. The animated image 
is implemented using CALayer, which handles all the drawing.

The image surrounding the pointer is an NSImage object containing two image 
representations, created as a TIFF file by Xcode from a normal and a @2x PNG 
image file. I have examined the combined TIFF image file in the built 
application, and it looks correct when opened in Preview. In fact, I can drag 
the Preview window onto the HiDPI screen and it looks correct -- no pixellation 
appears in the HiDPI image representation.

The documentation says that an NSImage-based layer will automatically choose 
the image representation with the correct scale in most situations, but, not 
surprisingly, this is apparently not one of those situations.

In an attempt to force the CALayer object to draw the correct image 
representation, I have written a simple routine using NSTrackingArea to detect 
when the pointer enters a new screen. My implementation of the -[NSResponder 
mouseEntered:] method is called every time the pointer enters a new screen, and 
an NSLog() call shows the screen's backingScaleFactor as 2.0 or 1.0 depending 
on whether it is a retina display screen or not. Another NSLog() call shows 
that the image contains the two image representations, as expected. I then try 
a variety of techniques to display the correct representation, but I always see 
a pixellated image. The simplest technique detects the backingScaleFactor of 
the newly-entered screen, creates a copy of the NSImage object, removes the 
representation with the wrong scale, and sets the layer's contents to the 
resulting NSImage object. An NSLog() call confirms that the layer's contents 
are the single image representation with the correct scale. But it is drawn 
pixellated. Setting the contentsScale of the overlay window's contentView to 
the backingScaleFactor of the screen does not help. Doing the same thing by 
setting the view to be the layer's delegate and triggering the -displayLayer: 
delegate method by sending the -setNeedsDisplay message to the layer when the 
pointer enters a new screen has the same problem.

My best guess is that the problem results from the fact that the overlay window 
spans all attached screens. An NSLog() call confirms that the window's 
backingScaleFactor is always 1.0 (because it is initially created on a 
non-retina display in my testing). There is no NSWindow method to 
-setBackingScaleFactor, so there appears to be nothing I can do about this. 
Reading the documentation about CALayer and HiDPI screens very, very carefully, 
I notice that it always assumes that the layer-hosting view is in a window that 
is being dragged across screen boundaries. Am I correct in guessing that a 
fixed multi-screen window simply isn't capable of displaying HiDPI images if 
the window started out with a backingScaleFactor of 1.0?

If that's correct, I guess I'll have to abandon my multi-screen overlay window 
and implement a multi-overlay-window solution, which is going to be a ton of 
work. Unless somebody can suggest a different approach using a multi-screen 
overlay window.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: HiDPI retina issue with multi-screen overlay window and Core Animation

[William J. Cheeseman]

On Jan 12, 2013, at 11:21 AM, Richard Somers  wrote:

> A single window which overlays multiple screens with each screen using a 
> possibly different backingScaleFactor. Wow!

It's the only way I could find to detect when the mouse enters any particular 
screen, using NSTrackingArea with -[NSResponder mouseEntered:]. My code for 
this is simple and quite effective except when a retina display is in issue. 
It's also very easy to reset the tracking areas when the user changes screen 
parameters.

> It seems like you have three options.


> 2. Use one overlay window for each screen and go with the flow of the 
> frameworks.

I have a demo working now, in which I set up a separate overlay window for each 
screen. It remains to be seen whether this will solve the retina display and 
Core Animation issues. I have left the multi-screen window for mouse tracking 
in place at the same time, at least for testing purposes.

> 3. Try cursor replacement. Take the current cursor image, combine it with 
> your image, and then somehow tell the system to use that.

I have no prior experience in this area. Can a cursor be created that animates 
using Core Animation?

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Detecting a native Cocoa app ?

[William J. Cheeseman]

On Feb 7, 2013, at 3:32 AM, dvlc...@gmail.com wrote:

> I would like to automatically detect when the target application is
> native cocoa, so that I may switch the plugin off otherwise. How would
> you do that ?


There is an Apple Q&A document that explains how to do that. It was published a 
couple of years ago.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Detecting a native Cocoa app ?

[William J. Cheeseman]

On Feb 7, 2013, at 3:32 AM, dvlc...@gmail.com wrote:

> I would like to automatically detect when the target application is
> native cocoa, so that I may switch the plugin off otherwise. How would
> you do that ?


ULI's answer makes sense if you are asking which frameworks are being used. 
However, you can determine which runtime environment, Cocoa or Carbon, the 
application is running in, which may be what you're really asking. The Apple 
Q&A I mentioned earlier is QA1372. Here's the link: 
.

-- 


Bill Cheeseman - b...@cheeseman.name

___

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

Problem with NSDatePicker in popover

[William J. Cheeseman]

My Mac OS application has an NSDatePicker object in a popover. When the popover 
opens, the date picker works perfectly. 

However, when I detach the popover to its own window, the date picker no longer 
highlights the selected date picker element. The date picker still works 
perfectly in all other respects: I can use the tab key to select different date 
picker elements (since they aren't highlighted, I have to count the number of 
tab presses in my head to know which element is selected). I can use the 
up-down arrows or even type a new value for the year, month or day to change 
the value. I can tab on out to the next key view. I can even tab around the 
entire key view loop and back to the date picker, and then set its values 
again. The associated instance variable's value is properly udpated every time. 
But the selected date picker element is not highlighted.

Actually, when I first detach the popover, I very briefly see the first date 
element highlighted, but it immediately unhighlights. My 
-detachableWindowForPopover: delegate method seems to work correctly, but it 
looks as if something happens after that to make the highlighting in the date 
picker go away. NSLog calls confirm that the date picker is enabled and its 
date picker cell is selected. I have made the date picker the detached window's 
first responder and the key view loop is set up correctly. I am instantiating 
separate controllers and views for the anchored popover and the detached 
popover as per the documentation.

Has anybody seen this behavior? Is this enough of a description for anybody to 
suggest where I should look next for the problem?

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Problem with NSDatePicker in popover

[William J. Cheeseman]

On Feb 23, 2013, at 1:35 PM, Keary Suska  
wrote:

> Your description suggests that you aren't using separate UI elements for the 
> window and the popover as required by the docs...?


When I said "I am instantiating separate controllers and views for the anchored 
popover and the detached popover as per the documentation," I meant that I 
alloc and init separate view controllers for the anchored popover and for the 
detached popover window. The anchored popover has one view controller. The new 
view controller for the detached popover window initializes itself by loading 
the nib file for the view, and I assign the new view as the content view of the 
new popover window. I believe that results in separate UI elements for the 
popover and the window. I even have to explicitly set the values in the new UI 
elements to match the values they had in the anchored popover -- otherwise, the 
new UI elements are empty.

The only substantive difference between my application and Apple's Popover 
sample code is that Apple instantiates both popover view controllers in the 
mainmenu nib file, both of them based on the same NSView subclass. I 
instantiate my two popover view controllers separately in code, both of them 
based on the same NSView subclass. I instantiate the new detached popover 
window's view controller lazily in the -detachableWindowForPopover: delegate 
method. My way, if the user never creates a detached popover window by dragging 
the anchored popover away from the parent window, I never have to create its 
view controller and view.

Did I understand you correctly?

-- 

Bill Cheeseman - b...@cheeseman.name



-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Problem with NSDatePicker in popover

[William J. Cheeseman]

On Feb 23, 2013, at 1:35 PM, Keary Suska  
wrote:

> Your description suggests that you aren't using separate UI elements for the 
> window and the popover as required by the docs...?


I just discovered that Apple's Popover sample code exhibits exactly the same 
problem when I add a date picker to its popover view! The date picker looks and 
works as it should when the popover is anchored to its parent window, but it 
does not highlight its selected date picker elements after the popover is 
dragged out to its own detached window. 

This strongly suggests that there is a bug in NSDatePicker.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Problem with NSDatePicker in popover

[William J. Cheeseman]

On Feb 23, 2013, at 2:46 PM, "William J. Cheeseman"  
wrote:

> I just discovered that Apple's Popover sample code exhibits exactly the same 
> problem when I add a date picker to its popover view! The date picker looks 
> and works as it should when the popover is anchored to its parent window, but 
> it does not highlight its selected date picker elements after the popover is 
> dragged out to its own detached window. 
> 
> This strongly suggests that there is a bug in NSDatePicker.


Using Apple's Popover example with a date picker added to its popover view, I 
made MyWindowController the delegate of the popover view and implemented the 
-windowDidBecomeKey: delegate method. In it, I test whether the window that is 
becoming key is the detached popover window, and if it is I call sleep(1). 
Then, when I run the application and detach the popover to its own window, the 
first date picker element is properly highlighted for one second. Then the 
highlighting disappears and at the same moment the original parent window loses 
its key window appearance.

So, it's something about the window connection that's causing the misbehavior, 
but I can't seem to put my finger on it conceptually.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Problem with NSDatePicker in popover

[William J. Cheeseman]

On Feb 23, 2013, at 3:32 PM, "William J. Cheeseman"  
wrote:

> Using Apple's Popover example with a date picker added to its popover view, I 
> made MyWindowController the delegate of the popover view


Correction: I made MyWindowController the delegate of the detachedWindow object 
in MyMenu.xib.

When a popover is still anchored to its parent window, the popover view's 
window is the parent window -- which makes sense, when you think about it, 
because a popover is just another view in the main window. When the popover is 
detached, the new, separate popover view's window is the detached popover 
window. 

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Problem with NSDatePicker in popover

[William J. Cheeseman]

On Feb 23, 2013, at 4:04 PM, William J. Cheeseman  wrote:

> When a popover is still anchored to its parent window, the popover view's 
> window is the parent window -- which makes sense, when you think about it, 
> because a popover is just another view in the main window. When the popover 
> is detached, the new, separate popover view's window is the detached popover 
> window. 


And now, simply by fooling around, I have discovered that you can solve the 
problem at runtime by clicking in the Finder or some other application and then 
clicking back in the detached popover window. 

But when I try to profit from this observation by making the parent window key 
after the detached popover window becomes key, and then immediately (or even 
after a delay) making the popover window key again, the application goes into 
the spinning rainbow world and crashes after a while -- both in my application 
and in Apple's Popover sample application.

That's enough for me for today.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Problem with NSDatePicker in popover

[William J. Cheeseman]

On Feb 23, 2013, at 10:01 PM, Graham Cox  wrote:

>> When a popover is still anchored to its parent window, the popover view's 
>> window is the parent window -- which makes sense, when you think about it, 
>> because a popover is just another view in the main window.
> 
> Are you sure about that? I'm not... it would make sense to me if the popover 
> window was a separate window, a child of the original window. That's how it 
> acts and behaves. For example if the popover falls outside the bounds of the 
> original view or window, it has its own shadow etc, and is unclipped by the 
> original window. The internal pointers to the view's window might return some 
> other window of course, but I don't think so - I have tried for example, to 
> attach a sheet to a popover by asking for the view's -window as the sheet's 
> parent and it attached the sheet to the popover. Turned out to be a bad idea, 
> but it worked, sort of.

You're right in terms of the underlying implementation of NSPopover. In any of 
the NSPopover delegate methods, log [[[popover contentViewController] view] 
window] or notification object] contentViewController] view] window] and 
you'll get a window object whose iVar is _NSPopoverWindow. You can do 
essentially the same thing to get the window of a drawer's content.

What I was getting at is how the date picker in the popover sees the world. I 
subclass NSDatePicker in order to intercept the key down event, then I log the 
window of the event. When the date picker is in the anchored popover, the event 
window is the parent window, not the private popover window, and the date 
picker works as expected. When the date picker is in the detached popover 
window, the event window is, as expected, the newly created detached popover 
window -- and the date picker doesn't highlight its elements (although it works 
correctly in every other respect).

I assume that the change in window is the source of the problem with the date 
picker's highlighting behavior after the popover is detached. But I don't 
understand exactly what's happening, or what I can do about it.

>> When the popover is detached, the new, separate popover view's window is the 
>> detached popover window. 
> 
> 
> Do you need to call -makeKeyAndOrderFront: on the detached window?

I tried that and it does nothing. That was expected, because I implement 
-windowDidBecomeKey: in the parent window controller and it is triggered when I 
detach the popover -- and the notification object is the detached window.

-- 

Bill Cheeseman - b...@cheeseman.name


___

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

Re: Problem with NSDatePicker in popover (workaround)

[William J. Cheeseman]

On Feb 24, 2013, at 6:33 AM, Graham Cox  wrote:

> If you've done all that and it's still not working as expected, maybe there's 
> a subtle bug in the code that animates between the popover and the new 
> window. This being newish code, it's possible.

I've done all that, and I believe it is a bug. Now that I've found a 
workaround, I will report it to Apple.

> I have frequently found that Apple's own sample code isn't always as thorough 
> as it could be, so just using sample code as boilerplate may not have 
> considered all these issues; it might not be a bug but just something the 
> sample code didn't bother with.


Understood; that's my experience, too. Given the awkwardness of the workaround, 
however, it seems more likely that it is a bug.

Here's the workaround I came up with, tested in Apple's Popover example but not 
yet tested in my own application. Implement the -windowDidBecomeKey: delegate 
method in the main window's window controller, as follows:

- (void)windowDidBecomeKey:(NSNotification *)notification {
if ([[notification object] isEqual:detachedWindow]) {
// Disable delegates to avoid infinite loop.
[[self window] setDelegate:nil];
[[notification object] setDelegate:nil];

// Make main window key, then make detached popover window key.
[[self window] performSelector:@selector(makeKeyAndOrderFront:) 
withObject:nil afterDelay:0.0];
[[notification object] performSelector:@selector(makeKeyAndOrderFront:) 
withObject:nil afterDelay:0.0];

// Re-enable delegates.
[[self window] performSelector:@selector(setDelegate:) withObject:(id 
)self afterDelay:0.0];
[[notification object] performSelector:@selector(setDelegate:) 
withObject:self afterDelay:0.0];
}

If you want to test this yourself in the Popover example, be sure to connect 
the delegate attribute of the popover window in MainMenu.xib to 
MyWindowController, and add a date picker to the view in PopoverView.xib.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Problem with NSDatePicker in popover (workaround)

[William J. Cheeseman]

On Feb 24, 2013, at 8:04 AM, William J. Cheeseman  wrote:

> Here's the workaround I came up with, tested in Apple's Popover example but 
> not yet tested in my own application. 


It works in my own application, too. All is well with the world once again.

Thanks for the help.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Problem with NSDatePicker in popover (workaround)

[William J. Cheeseman]

On Feb 24, 2013, at 8:04 AM, William J. Cheeseman  wrote:

> Here's the workaround I came up with, tested in Apple's Popover example but 
> not yet tested in my own application. 


It works in my own application, too. All is well with the world once again.

Thanks for the help.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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

Re: Problem with NSDatePicker in popover (workaround)

[William J. Cheeseman]

On Feb 24, 2013, at 8:25 AM, William J. Cheeseman  wrote:

> On Feb 24, 2013, at 8:04 AM, William J. Cheeseman  
> wrote:
> 
>> Here's the workaround I came up with, tested in Apple's Popover example but 
>> not yet tested in my own application. 
> 
> 
> It works in my own application, too. All is well with the world once again.

Bug Reporter id# 13281356.

-- 

Bill Cheeseman - b...@cheeseman.name

___

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