Thanks for the suggestion. I tried that out. However, this has the same issue as the other things which I tried. When the callback function is slow (I tried using time.sleep(0.1)) the stage is not redrawn anymore (i.e. 0 fps). Instead, the function is called again. I would expect the framerate to drop slightly below 10 fps instead.
One reason why I am concerned about this (which doesn't have to do anything with the UDP device) is that I will need a texture loader which should load lots of textures while the stage should be still rendered as smoothly as possible. This means that it should load only a few textures in every mainloop iteration. Now let's assume it takes 0.1 seconds to load a middle-sized texture. If I put the textures in a queue list and call an idle function which loads one texture per call, the application will hang, i.e. the stage is not rendered until *all* textures are loaded. Any thoughts about this? Thomas On Thu, Dec 25, 2008 at 4:20 PM, Grahame Bowland <[email protected]> wrote: > 2008/12/25 Thomas Steinacher <[email protected]>: >> Hello, >> >> I have a certain device which sends messages via UDP. These messages >> have effect on the stage rendering, which means I need to get them >> periodically. The question is, what's the best way to do this? The >> callback should be triggered between every redraw, i.e. there should >> be no two stage redraws without the callback being called between the >> redraws. Also, if the callback triggers a redraw, it shouldn't be >> called again until the redraw happened. If the callback doesn't >> trigger a redraw, it should be called again "very soon" (= n times per >> second) to check for messages again. > > If you're using UDP, then you can ask the glib mainloop to call your callback > whenever there is data available on the socket. In the python bindings you'll > want to use glib.io_add_watch. Then your callback will run whenever new > messages arrive from your device. > > Cheers > Grahame > -- To unsubscribe send a mail to [email protected]
