Re: [MACTCL] Tk-Cocoa 2.0

[Kevin W. <kw...@co...>]

Hi Russell and Torsten,

On 2/13/15 7:25 PM, Russell Owen wrote:
>
>>> It seems it could have something to do with timing. If the 
>>> application has enough time to adjust, then OK, but if the change is 
>>> �too radical� or just too quick (too many events in a short time?), 
>>> then the crash occurs. This is reproducible in 9 out of 10 times.
>> It's setting window visibility to false and disabling screen updates, so
>> it may not be able to keep up with a rapid stream of events. I may just
>> have to take that out and leave a bit of flicker during resize--it will
>> still be reduced because of the other changes I've made. I'll report
>> back soon.
>
> I personally would rather have the flicker than the delay in the start 
> of resizing. But either way works and it is your call, since you are 
> doing the work!
>
> I realize a null result isn't much help but I tried rapidly resizing 
> some windows on my system (MacOS X 10.9.5 using the 8.5 branch of 
> tcl/tk checked out earlier today) and I have not been able to induce a 
> crash. That's with a plain wish window and with two applications I wrote.
>

I think I've fixed the issue: I was doing multiple calls to 
NSDisableScreenUpdates() and NSEnableScreenUpdates(), as well as setting 
the state of the main NSView to hidden, during resize events--once 
during the actual resize event, and also during the notification of the 
resize event. It was the NSNotification call that seemed to be clogging 
the event loop and causing the crash; removing those calls, but leaving 
them during the resize, preserves the smoothness I was striving for, but 
doesn't trigger any crashes in my testing. (I was testing this using the 
TkChat app I maintain, which I was able to crash consistently when 
resizing it quickly.)

See if the new commits help the issue on your end.

Thanks,
Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com