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
