all pi3d operations must be on the main Python thread.

[rec]

This took me a long time to boil down into a tiny test case. I still don't have a good fix for it in general though I can work around it in my codebase.

Take a look at this piece of test code. There's a tiny event_loop in a function called "event_loop" which simply displays a header image and nothing else.

You can see from the code that if you set ENABLE_BUG to False, event_loop runs in the main thread - if it's True, then the event loop runs in a new Python thread.

If you run the code with ENABLE_BUG=False, then you see the correct pink window with a header. If you run the code with ENABLE_BUG=True, you see a white screen with nothing in it.

(Note that if you set ENABLE_BUG to True, the program won't terminate with a control-C - you have to kill it from a separate terminal instance. This is expected behavior for Python threads - I could have put code to avoid that happening but didn't want to obscure the issue.)

[rec]

I just updated the bug title.

It turns out that any operation - even loading textures - has to run on the main Python thread.

This is really draggy if you're dynamically loading textures, because that loading has to run on the main thread - putting file IO on your display thread doesn't sound like a good idea, does it?

But at least it's a simpler-to-understand bug.

[alextz]

rec, you just saved me a lot of time. I'd have found this bug the hard way.

Oddly enough, within the last week, I've found the same problem with a frame grabber on an Ubuntu PC. My not-yet-implemented solution is to put the frame grabber's logic in a subprocess and push the frames through a queue. I did some prelim testing and think the queue will not be a serious CPU hog.

Same thing might work in your (and my) case. The big time hog in loading textures is the image load, resizing and conversion. Once the thing is in a string, it can be pushed down a queue pretty fast, probably.

[rec]

Very glad to have helped.

It turns out that most of the computations associated with loading textures can be done on any thread - there are only some small key operations that must be done on the display thread.

Our alternate development branch has such a fix mostly implemented, but it will be some time before this is all ready to go...

[rec]

This needs to be fixed in THREE ways - we need to complete the changes involving the split of loading, we need to check to see that you're in the correct thread and report an error if you don't, and we need to document this better...

[rec]

I think this is basically done!