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 <witness.of.teacht...@gmx.net> wrote: > On 27 Apr 2015, at 10:53, Nisar Ahmed <nisar....@gmail.com> 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 (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
