Re: long computation in TK

"Holy Windows 3.1, Batman!" A much better strategy would be to launch a (single ...) background thread to recompute the bitmap, then signal you by some means that the computation is done so that you can in one step replace the existing bitmap with the recomputed one. Your present strategy will, at best, make the display look very strange for about 30 seconds, and take a whole lot longer due to Tk overhead.

Comment on Re: long computation in TK

Replies are listed 'Best First'.
Re^2: long computation in TK by Marshall (Canon) on Jun 26, 2018 at 08:51 UTC
I may be wrong about this, but I don't think that Tk is "thread-safe".	[reply]
Re^3: long computation in TK by Corion (Patriarch) on Jun 26, 2018 at 08:55 UTC
Usually, Tk is not thread safe. Which is why there is only one thread talking to Tk, and the other thread doing the work. The worker thread is not allowed to speak to Tk. Usually, the two threads communicate through a Thread::Queue.	[reply]
Re^4: long computation in TK by Anonymous Monk on Jun 26, 2018 at 12:55 UTC
Calculate the bitmap using other tools then provide it all-at-once to the parent process to insert into the Tk-driven display. The updated bitmap should "just appear, all at once, poof." There's more than one way to do it.	[reply]
Re^5: long computation in TK by Marshall (Canon) on Jun 27, 2018 at 20:30 UTC
Re^2: long computation in TK by BillKSmith (Monsignor) on Jun 26, 2018 at 19:03 UTC
How sentient! Twenty years ago, I wrote a version of this program in C++ for 3.1. The executable failed to load in XP. The source was backed up on floppy (long since discarded). I do remember solving the analogous problem in an analogous way. It recently occurred to me that modern hardware could probably compensate for the overhead of Tk and perl. I was right. My current version achieves slightly better performance than I remember from the ancient past. Bill	[reply]