Re^3: long computation in TK

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.

Comment on Re^3: long computation in TK

Replies are listed 'Best First'.
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
I ran one version of the code and it worked fine on my development machine. Calling the GUI display function for each row is very CPU intensive. However this is not a "bad" idea. My Win XP laptop test machine has died. I lament that loss because if I can get the GUI to work on a very slow machine, it will work like magic on a fast machine. Sometimes we developers assume that the users have machines like we have (many cores, min of 16 GB memory), etc. That in general, is not true. Unless you can calculate the whole thing in less than one second, I figure a more CPU intensive process that actually takes longer for the full result is generally better. If the UI "hangs" there are problems with that.	[reply]