On Thu, 2008-09-25 at 00:48 +0100, Robert Bragg wrote:
> The nicest approach we've come up with so far seems to be getting
> Clutter to internally push the rendering out to a worker thread by
> moving the calls to glXSwapBuffer into a new thread. Since writing multi
> threaded GL apps is pretty common amongst game developers etc I think
> there should be very little risk for Clutter to internally start doing
> GL calls from different threads. This approach also completely hides
> threading issues from developers. (Usually for the win!)
except:
- the locking system will have to be re-evaluated because if you
are accessing GLib data structures from different threads you
must have locking in place
- Clutter requires to be linked against gthread-2.0
- Clutter requires every application to initialize the threading
code paths in GLib/GObject
- or -
- Clutter needs to initialize the threading code paths in GLib
and GObject
- we need a MainContext-aware API for our internal API dealing
with the main loop, since we're now using the default main
context
and while GLib data structures and MainLoop are usually thread safe,
GType instantiation is not entirely thread safe (try creating two new
instances of the same class from the same thread).
not that I'm saying this should not be done: I'd rather go along the way
of using threads and solve a lot of the performance issues; what I'm
saying is that this is not a change that will be implemented overnight.
> Note, this stuff is still in the stages of discussion/experimentation,
> so no guesses if this will actually make it into Clutter proper any time
> soon, or if we might come up with a different approach. If you are
> interested in experimenting with the patches please feel free to give
> feedback. Of course you'll also need to tweak the python bindings for
> clutter_stage_get_actor_at_pos yourself for now.
threading and python are two very different beasts, with different
interactions at different levels. python is using user-level threads in
its API, as far as I know, and this is already not entirely well
behaving with the concept of GLib thread safety. so, beware and caveat
emptor apply.
ciao,
Emmanuele.
--
Emmanuele Bassi, Intel Open Source Technology Center
--
To unsubscribe send a mail to [EMAIL PROTECTED]
