Re: Cocoa window stops responding
Re: Cocoa window stops responding
- Subject: Re: Cocoa window stops responding
- From: Nisar Ahmed <email@hidden>
- Date: Wed, 29 Apr 2015 10:38:06 +0500
I think I have found the culprit, I have subclassed NSOpenGLView where in
drawRect, I am rendering a IOSurface based texture using CVDisplayLink,
although I don't know why it is causing the screen to freeze but when I
moved the rendering code from CVDisplayLink to dispatch timer the problem
seems to have disappeared. Inside CVDisplay callback I was calling [view
setNeedsDisplay:YES] which I think is a correct way of calling drawRect
from background thread? while inside timer I am directly calling [view
drawRect:NSZeroRect].
I still need to know why...
On Mon, Apr 27, 2015 at 3:22 PM, Uli Kusterer <email@hidden>
wrote:
> On 27 Apr 2015, at 10:53, Nisar Ahmed <email@hidden> wrote:
> > My application has a UI having a main window which contains many views
> such
> > as NSTableView, NSOutlineView, NSOpenGLView, many NSTextFields etc...
> >
> > The applications works normally but after some time the UI stops
> responding
> > to the mouse clicks, the application does not hang but it seems that all
> > the views stop redrawing itself. I have tried many things but fails to
> > prevent or reproduce the behaviour. Need some advice on how to fix or
> > atleast find out what is causing such behaviour.
> >
> > I am updating all UI controls on the main thread and using Cocoa bindings
> > heavily.. apparently there is no memory leaks, I am using Xcode 6.1 on
> > Mavericks
>
> My first suspects if a window stops drawing are always:
>
> 1) Drawing attributes that bleed out (e.g. setting the color to white at
> some point but never back to black, so the next iteration starts out with
> white instead of the default black) and aren’t wrapped in saveGState
>
> 2) Calls to setNeedsDisplay: or display or the like while a drawRect: is
> running (e.g. setNeedsDisplay: causes drawRect: which sets a property that
> calls setNeedsDisplay: again which causes a drawRect: on the next run loop
> iteration, making your Mac constantly redraw stuff until that’s all it
> does, or even worse manipulating the view hierarchy while the OS is
> iterating views to draw them).
>
> 3) Threaded code that manipulates the UI from another thread than the main
> thread. There are very few, very specific circumstances under which you may
> manipulate and draw views and view hierarchies on a non-main thread (or
> call setNeedsDisplay: or display), so if you do not for a fact know that
> this is documented as being OK, you probably shouldn’t do it. This case in
> particular has often screwed up drawing in such a way that the entire
> window just became a white sheet.
>
> I presume you’ve done the usual, i.e. ran Analyze and fixed all it
> complained about, as well as Instruments.
>
> Cheers,
> -- Uli Kusterer
> “The Witnesses of TeachText are everywhere...”
> http://zathras.de
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden