Re: [MACTCL] [TCLCORE] Commits to improve drawing in Tk-Cocoa after removal of private API's

[Kevan H. <ha...@br...>]

Dear Kevin,

Thank you for all the work you are doing to keep Tk going on MacOS.

> Re-engineering either of these foundational parts of Tcl would, as I 
> understand it, go far beyond adjusting a platform-specific 
> implementation of the current API

Indeed it would. But the Tcl event loop has one severe limitation, and I 
believe it's the one Michiel is referring to. I had to build my own 
event loop on top of Tcl's, because Tcl's would not do the job.

The problem with Tcl's event loop is that pending "vwaits" are resolved 
strictly in reverse order of initiation, and "after" events are ignored 
during an active vwait.

Suppose I am capturing images from a server on the Internet as fast as I 
can. As soon as one comes in, I post and "after" event to the Tcl event 
loop. While waiting for each image to arrive, Tcl is in its vwait state, 
servicing call-backs, but not  "after" events, nor will it do anything 
about other "vwaits" that have terminated. If, during this thge image 
capture vwait, I happen to press a button on another window that asks 
for the temperature of the camera, this other data acquisition process 
begins, but it cannot terminate because the server is busy capturing an 
image. So it vwaits. But of course the original image capture is what's 
holding things up, and that won't terminate until this vwait has 
terminated, which won't happen until it itself has terminated. So we're 
stuck.

There's a name to this kind of stoppage, but I can't remember what it is.

All the event loop has to do is return control to whatever vwait or 
after event occurs first, and all will be well. There are problems 
associated with such an open-ended event loop, but they are handled with 
a little discipline, and the resulting structure is far more versatile 
and efficient.

If Tcl has to "vwait" for Cocoa, and Cocoa is assuming that many 
requests for action come in at the same time, then I can see that the 
interaction between Tcl and Cocoa cannot work within the Tcl event loop.

 > I find it hard to imagine that there would be
> much support for changing the event loop (this would require a large 
> effort across every platform)

I have written several event loops in my time, one of them in assembler. 
They are not complicated compared to the kind of detailed graphics code 
you have been working on. But I agree that there is no chance of the Tcl 
core team changing the way the event loop is done. I am sure they have 
many reasons to prefer the strict reverse-order vwait system, although I 
can't tell you what those reasons might be.

Is it possible to build your own graphics event loop with which to 
interact with Cocoa? I of course speak from a position of near-complete 
ignorance of the problems you are faced with, so forgive me if I have 
wasted your time.

Yours, Kevan

-- 
Kevan Hashemi, Electrical Engineer
Physics Department, Brandeis University
http://alignment.hep.brandeis.edu/