[Openmcl-devel] Re: [Bug-openmcl] NSViewHierarchyLock Assertion failure

[Raffael Cavallaro]

On May 14, 2004, at 12:23 PM, Gary Byers wrote:

> Here's another version; it's probably not a good example of how to do
> animation, and it may use enough CPU cycles to cause the occasional
> PowerBook meltdown ...

Thanks very much for this. It only seems to go to 40% CPU with one 
window.
I can, however, get it to 175% CPU on a dual 2GHz G5 with 80 other 
processes running by doing:
(dotimes (n 10) (ccl:animate))

It nevertheless seems quite stable, and closing windows and creating 
new ones willy nilly has no negative effects. And, as promised, your 
modifications are (to my eye at least) quite clear and easy to follow.



With 10 windows animating at the same time one does see the problem 
with failing to update invalid regions that you point out:

> The bad news is that the drawRect: method - used
> to automatically update invalid view rectangles from the main thread -
> is a no-op, so portions of the view that're exposed don't get redrawn
> until the next animation cycle.  Fixing this is left as an excersise
> (hint: don't allow the view's NUMSIDES instance variable to change
> unless the view is locked for drawing.)

This exercise is my next openmcl task.

Thanks again.

Ralph


P.S.
What follows might be considered cruel and unusual punishment, but I 
thought you might be interested as it is an outright hang.
Really beating on it by trying to create 20 animation windows while 
iTunes is playing an mp3  can cause OpenMCL to hang outright 
(Application Not Responding) with the console error:

2004-05-14 14:11:57.371 dppccl[2473] *** Assertion failure in 
-[NSViewHierarchyLock unlockTopMostReader], 
AppKit.subproj/NSViewHierarchyLock.m:428

I first saw this from the IDE (I do most cocoa stuff from the IDE since 
it launches instantly, and (require 'cocoa) takes quite a while to 
load). However, even when run from a terminal, I am not dropped into 
the kernel debugger, so I can't give any kernel debugger output for 
this.

Sometimes when I do this torture test, rather than hanging with the 
above console error, OpenMCL will just enter a break loop:

 > Error in process Listener(5): Objective-C runtime exception:
 >                               Error (268435471) creating CGSWindow
 > While executing: CCL::CHECK-NS-EXCEPTION

Anyway, maybe some of this is useful information for bulletproofing the 
cocoa bridge.

Once again, many thanks.

Ralph

Raffael Cavallaro, Ph.D.
raffaelcavallaro at mac.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2527 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20040514/5b2add28/attachment.bin>