On 1 Oct 2020, at 19:47, lifeattickville wrote:
> 
> > The "historical" model for GUI programs is the main process is the GUI handler thread, and if there is significant, potentially blocking activity, it takes place in secondary threads. 
> 
> Tho, thinking about it for 5 seconds, I don't see why the GUI thread couldn't be a secondary thread ... 


Because, historically, the GPU context belongs only to the main thread, and historically GPU drivers were a very long way from being thread-safe.

Remember that for folks writing GPU drivers the mantra was *never*  “do not be wrong” it was always “do not be slow.”

Things have got a bit better in recent years, particularly since the games houses started trying to use all those extra cores - that has somewhat forced the GPU folks to clean up their act a bit, so things *can* work like that now. On some machines. With some GPU drivers.

But generally, if you want your code to be robust and portable, don’t try and manipulate the GUI context from a non-main thread. It may not be convenient, but it less painful in the long term!

I have, more than once, had to dig folks out of a hole of their own making, for this exact issue - they had code that worked “perfectly" on their dev machine, using a  non-main GUI context, and then burned in inexplicable bug-ridden fury when run on a user machine.

Maybe someday that will be fine. But not yet...

-- 
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/4786FC5E-CF0C-4AF5-B56E-B17AC49C058E%40gmail.com.