Re: Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread James Walker 

On 12/13/18 1:35 PM, Rob Petrovec wrote:




On Dec 13, 2018, at 2:26 PM, James Walker  wrote:

On 12/13/18 11:05 AM, Matt Jacobson wrote:

The buffered nature of the Mac OS X window system means that windows can 
“display” (i.e., go through the process of updating) even when ordered out.  
Ordered-out windows /can/ occasionally be seen on screen (consider App Exposé, 
which shows minimized windows, or Show All Tabs in apps using NSWindow 
tabbing), and the system may snapshot or display ordered-out windows for 
various reasons at other times, too.
In general, I’d say: you should not /rely/ on the fact that ordered-out windows 
are displayed—in the future, the system might choose to defer it as an 
optimization—but neither should you expect it not to happen.
Simply bailing out of -drawRect: (which, incidentally, is called on /views/, 
not windows) seems like a bad idea, since the window may display into an 
invalid state, which could result in corruption.  I’d instead investigate the 
underlying cause of the crash, which may result from your view attempting to 
use an object that it does not hold a strong (or weak-upgraded-to-strong) 
reference to.


The view was using a C++ object that had been destroyed during closing of my 
document.  I'm afraid that if I start playing with the order of destruction, 
I'm likely to break something else.  But I can be more precise about when I 
decline to draw, by having my document post a notification when it starts to 
shut down.



If it’s a C++ object then reference it in your view with a weak_ptr so 
you can tell when/if it has been disposed of.



Oh, cool!  I didn't get around to using C++11 until about a year ago 
(yes, I'm behind the curve), and I read a number of "what's new in 
C++11" web pages, but somehow I missed std::weak_ptr.




On Dec 13, 2018, at 10:44 AM, James Walker mailto:jam...@frameforge3d.com>> wrote:

I was getting a crash on quit resulting from a drawRect: method being called on 
a window that had been ordered out.  I can solve the immediate problem just by 
bailing out of drawRect: if the window is invisible, but I wish I understood 
what's going on.  The call stack shows a run loop observer calling 
CA::Transaction::commit() resulting in -[NSWindow displayIfNeeded] being 
called, but I don't know why displayIfNeeded would do anything with an 
invisible window.


___

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/petrock%40mac.com

This email sent to petr...@mac.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

Re: Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread Jens Alfke 


> On Dec 13, 2018, at 1:26 PM, James Walker  wrote:
> 
> The view was using a C++ object that had been destroyed during closing of my 
> document.  I'm afraid that if I start playing with the order of destruction, 
> I'm likely to break something else.  

An NSDocument won’t be dealloced until all of its windows have been closed and 
released.
It’s been many years since I used NSDocument, but it sounds like you shouldn’t 
be deleting this C++ object when the document is being closed; wait until it’s 
dealloced.

—Jens

___

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: Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread James Walker 

On 12/13/18 11:05 AM, Matt Jacobson wrote:
The buffered nature of the Mac OS X window system means that windows can 
“display” (i.e., go through the process of updating) even when ordered 
out.  Ordered-out windows /can/ occasionally be seen on screen (consider 
App Exposé, which shows minimized windows, or Show All Tabs in apps 
using NSWindow tabbing), and the system may snapshot or display 
ordered-out windows for various reasons at other times, too.


In general, I’d say: you should not /rely/ on the fact that ordered-out 
windows are displayed—in the future, the system might choose to defer it 
as an optimization—but neither should you expect it not to happen.


Simply bailing out of -drawRect: (which, incidentally, is called on 
/views/, not windows) seems like a bad idea, since the window may 
display into an invalid state, which could result in corruption.  I’d 
instead investigate the underlying cause of the crash, which may result 
from your view attempting to use an object that it does not hold a 
strong (or weak-upgraded-to-strong) reference to.


The view was using a C++ object that had been destroyed during closing 
of my document.  I'm afraid that if I start playing with the order of 
destruction, I'm likely to break something else.  But I can be more 
precise about when I decline to draw, by having my document post a 
notification when it starts to shut down.


Thanks for the reply.

On Dec 13, 2018, at 10:44 AM, James Walker > wrote:


I was getting a crash on quit resulting from a drawRect: method being 
called on a window that had been ordered out.  I can solve the 
immediate problem just by bailing out of drawRect: if the window is 
invisible, but I wish I understood what's going on.  The call stack 
shows a run loop observer calling CA::Transaction::commit() resulting 
in -[NSWindow displayIfNeeded] being called, but I don't know why 
displayIfNeeded would do anything with an invisible window.


___

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: Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread Matt Jacobson 
The buffered nature of the Mac OS X window system means that windows can 
“display” (i.e., go through the process of updating) even when ordered out.  
Ordered-out windows can occasionally be seen on screen (consider App Exposé, 
which shows minimized windows, or Show All Tabs in apps using NSWindow 
tabbing), and the system may snapshot or display ordered-out windows for 
various reasons at other times, too.

In general, I’d say: you should not rely on the fact that ordered-out windows 
are displayed—in the future, the system might choose to defer it as an 
optimization—but neither should you expect it not to happen.

Simply bailing out of -drawRect: (which, incidentally, is called on views, not 
windows) seems like a bad idea, since the window may display into an invalid 
state, which could result in corruption.  I’d instead investigate the 
underlying cause of the crash, which may result from your view attempting to 
use an object that it does not hold a strong (or weak-upgraded-to-strong) 
reference to.

Matt

> On Dec 13, 2018, at 10:44 AM, James Walker  wrote:
> 
> I was getting a crash on quit resulting from a drawRect: method being called 
> on a window that had been ordered out.  I can solve the immediate problem 
> just by bailing out of drawRect: if the window is invisible, but I wish I 
> understood what's going on.  The call stack shows a run loop observer calling 
> CA::Transaction::commit() resulting in -[NSWindow displayIfNeeded] being 
> called, but I don't know why displayIfNeeded would do anything with an 
> invisible window.
> ___
> 
> 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/matthew_jacobson%40apple.com
> 
> This email sent to matthew_jacob...@apple.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

Why would a view be asked to draw after its window has been ordered out?

2018-12-13 Thread James Walker 
I was getting a crash on quit resulting from a drawRect: method being 
called on a window that had been ordered out.  I can solve the immediate 
problem just by bailing out of drawRect: if the window is invisible, but 
I wish I understood what's going on.  The call stack shows a run loop 
observer calling CA::Transaction::commit() resulting in -[NSWindow 
displayIfNeeded] being called, but I don't know why displayIfNeeded 
would do anything with an invisible window.

___

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