Yes, that is clearer. Thanks.

If DESTROY doesn't clean up a canvas, then that supports my impression of Tk encouraging memory leaks. If it is too difficult to have DESTROY clean up, then I would rather have DESTROY complain that I forgot to clean up.

But in a programming environment with OO and where exceptions can be thrown, I've come to consider any clean up that is not done from within a destructor (DESTROY in Perl) to be a bug. Expecting people to do the equivalent of matching up malloc() and free() calls is just the perfect recipe for bugs.

So I still interpret what you described as more you not successfully working around an ugly feature of Tk, even though it wasn't quite the feature I originally thought.

I get the impression that it wasn't actually the leaked memory that was the problem. It sounds like the real problem was the number of objects Tk had to sift through more than the memory size of the process. But that wasn't clear to me from your description.