hg: macosx-port/macosx-port/jdk: MACOSX_PORT-36: Toolkit.getScreenInsets() returns empty insets

[Mike Swingler]

Yes it does.

You probably aren't hitting any problems because your monitor geometry is not changing while you are testing (so the internal NSScreen instances that AppKit creates are still internally retained and valid), but the moment that a user plugs in a second monitor, which is very common on portables (especially when demo'ing!) those instances will be deallocated if you have not CFRetain()'d them for the timeframe you are using them.

Feel free to use the bug to clean up the whole area. I think the multiple usages of NSScreen may warrant the use of the CFRetainedResource helper class (which will even CFRelease() on the main thread for you if you specify it to).

On Jul 28, 2011, at 9:05 AM, Sergey Bylokhov wrote:

> Hi Mike,
> My change was done in the same way as it was done in CWrapper.NSWindow.screen, which is used in CPlatformView.enterFullScreenMode().
> As far I understand it has the same issue?
> 
> 28.07.2011 19:18, Mike Swingler wrote:
> 
>> On Jul 28, 2011, at 7:57 AM, Sergey Bylokhov wrote:
>> 
>>> Hi Mike,
>>> 
>>> Thanks for review the changes!
>>> 
>>>> There is a problem with this change set: you did not CFRetain() the screen pointer before bubbling it up to Java, and you also need to CFRelease() it when you are done. Otherwise, you will crash if the screen geometry is changing while this code is running.
>>>> 
>>>> It may be worth wrapping the NSScreen in it's own Java subclass of CFRetainedResource that will handle these details for you. As is, the thread safety is correct.
>>>> 
>>>> Should I file a bug on this?
>>> 
>>> Yes, it'll be good.
>> 
>> Done:<http://java.net/jira/browse/MACOSX_PORT-196>.


Regards,
Mike Swingler
Java Engineering
Apple Inc.