On Thu, 2008-09-25 at 10:06 +0100, Emmanuele Bassi wrote: (I think your clock might be wrong there?)
> what I meant was: pushing Clutter towards a heavier threads usage, in > itself is a worthy goal at that, will require some serious rethinking of > how the API should interact with threads. Ok, so just to be clear, are we agreed that while that may or not be a worthy goal, it is a completely separate discussion from the glXSwapBuffers idea? The extra thread doesn't need to worry about clutter's thread model because it doesn't do any clutter calls. I think Clutter's current threading model is fine and is the same as adopted by GTK and Java/Swing (and probably others). You can do whatever you like in any threads, but all GUI calls should be done in one elected main thread (the one that calls clutter_main). It sounds like a lot of pain for very little gain to make every clutter call truly thread safe. The current model encourages you to do the sensible thing which is to use single-threading wherever possible and if you want a lengthy calculation in a separate thread you can do that, but that thread should only notify the main thread to repaint instead of doing any GUI calls directly. - Neil -- To unsubscribe send a mail to [EMAIL PROTECTED]
