Re: [pygame] pygame+threading+windows

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

As other posters said, nothing about the functionality you mention is
something that needs threads (and even more importantly, threads will
definitely not make the functionality easier to implement - they
rarely do in any case). In particular, you said you want: "the
possibility to easily switch one part of my GUI on or off by
instantiating resp. deleting an object of the responsible class" - and
that's very easily done in a single thread by maintaining a list of
active objects with update calls that is iterated in the way James
suggested... and even if you used threads, you'd probably still need
to keep and maintain and iterate that list in some fashion to make
sure the threads know where they are supposed to draw in your window
(someone would need to allocate the shared gui space, threads or not).

However, I think the real factor that will determine whether threads
will be worth the trouble they bring will be performance, which is
something you haven't talked about at all

For instance, if you have a task to accomplish that takes multiple
seconds, or you have a task that takes near a second, but happens
frequently, you'll find that doing that task in your user interface
thread makes for a very unresponsive and unusable GUI.

Because of this, one very common and useful situation for threads is
to make your main thread completely responsible for everything about
the GUI, and then spawn threads for long running tasks which post
events to the main thread when the gui needs to do stuff, so that the
window is always responsive to clicks and stuff. In that model, it's
actually desirable to not let be doing any event handling or rendering
in the task threads, so that limitation is no biggie.

On 8/3/06, Lars Friedrich <lfriedri@xxxxxxxx> wrote:
> I need to get frames from a camera and display them on the screen. At
> the same time, I have to do some other stuff. I wrote a "Camera"-class
> which has a "getFrame" method, returning a frame in a numpy-array. Now I
> also have a "CamWindow"-Class (that inherits from "Thread") which will
> know which camera's frames are to be displayed. It works like this:
If your "getFrame" method is slow, like more than double digit
milliseconds or that, then threads may be interesting for you... and
if you do use the threads, you should make the threads post events to
the pygame queue, and you can easily "delete" threads by turning
"while 1" loops until "while self.keep_running" where keep_running is
a simple boolean flag that gets cleared before the thread is started,
and gets set by some other thread

also, Is it possible you want multiple processes? If you want multiple
windows with pygame (as opposed to drawing multiple things in the same
window) then you'd need multiple process. Also, how will the tasks you
originally thought of happening in different threads interact with
each other? If the interaction is pretty simple/infrequent the