Lan Barnes wrote:
On Sat, October 27, 2007 1:23 pm, Andrew Lentvorski wrote:
<big rant snipped>
Did you ever post this in comp.lang.tcl to ask if you might be missing
something? If not, may I forward this?
I would prefer that you didn't as I did indeed post about this in much
more technical detail. It was a while ago under a different email
alias, though. And I'm not prepared to dig my Tcl/Tk version of my VLSI
editor out of mothballs in order to answer the return questions. I'm
not going to get mad or try to stop you, but I'm not going to be very
helpful either. I've already let that problem go.
A lot of this stuff came from when I was designing a VLSI editor. The
problem is that you are managing millions of objects. And you may
actually have to draw *every single one*. And you may have to
interactively copy several thousand. Managing that kind of concurrency
without good language constructs is hard.
In addition, you need a high-speed canvas. It cannot put locks in the
way of every function call. It needs to batch up these calls, and it
needs to tell you when it gets done in a very timely fashion.
Amazingly enough, the interaction needs to look *very* much like the
OpenGL pipeline (which I eventually did migrate to).
No UI at the time was even close. Eventually I settled on OpenGL via
PyGtkGLExt on OS X. The GtkGLExt stuff stays mostly out of the way of
an OpenGL canvas and OS X preserves the canvas sufficiently in the face
of window raising, lowering, exposing, etc. that you don't bump into
needing to lock Gtk very often.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
