On Sun, 2008-04-13 at 10:43 +0200, Dirk Meyer wrote:
> Hi everybody,
>
> We (the Freevo Project) are searching for a new GUI lib to give the
> new Freevo 2.0 some eye candy. Clutter looks very good and may be our
> new GUI backend. I played with it and I have some questions maybe one
> of you can answer. I use pyclutter 0.6.
cool.
> First of all, the animation flicker sometimes. It look like the do not
> use sync to vblank. How do I enable it? I looked around and found
> clutter.feature_available(clutter.FEATURE_SYNC_TO_VBLANK) which
> returns True. How do I set a feature?
sync-to-vblank is automatically used unless clutter cannot enable it.
you're using pyclutter - aren't you also using an nvidia card,
perchance? there are some problems while using python, clutter and
drivers/libraries that require dlopen()-ing.
> The next question is about threads. I found out that some parts should
> be called from the clutter thread, most of them can be called from any
> thread. But what is thread safe? I know I can call threads_enter() and
> threads_leave, but do I need to? Is it safe to create an object
> without calling this functions? What about reading some attributes
> (e.g. get_x())? What about setting attributes?
Clutter is mostly thread-aware, not thread-safe. that is: if you acquire
the main lock (threads_enter()/threads_leave()) you are safe to use any
Clutter API. otherwise, you really aren't.
to use Clutter API from different threads you should split the UI
manipulation code from the rest of the application code; when you need
to modify the UI from a thread different than the one where the GLib
main loop is running, then you can install an "idle source" and call the
UI code from there:
def do_updates (data):
clutter.threads_enter()
# here it is safe to update the UI
do_stuff_with_clutter(data)
clutter.threads_leave()
# do not call again
return False
def queue_ui_updates (data):
gobject.idle_add (do_updates, data)
...
# from within any thread
queue_ui_updates (state)
the idle callback "do_updates" is guaranteed to be called from within
the same thread where the main loop is running.
> Now some fancy stuff we will need. You support gstreamer as video
> player inside clutter. We also want to support mplayer and xine. In
> xine we created our own video driver that writes to shared memory (it
> is a different process). If I understand it correctly we need to copy
> the content of each frame into a clutter.Texture() object. That will
> be done in C, ignore my Python example here. Can I lock the texture
> somehow when copying a new image it it?
texture uploads are atomic: they either succeed or they don't.
> Or is threads_enter enough?
see above, re: threads. the clutter-gst video sink is just using an
AsyncQueue to store the buffers, and an idle source to upload them to
the texture. it shouldn't be too much complicated to get data from xine
and push it to the texture in the same way.
> Is
> there anything else I have to do? What format does a Texture support?
> Only ARGB?
also YUV2, if the driver suppors it (there's a feature for that as
well).
> Including mplayer is a bit more tricky. IMHO the best
> option is to use XComposite? Has anyone ever tried including a
> XComposite as clutter Texture?
this I'll leave for others to reply. :-)
> OK, that's all for now. I hope someone can help us out here.
hope this helps.
ciao,
Emmanuele.
--
Emmanuele Bassi, OpenedHand Ltd.
Unit R, Homesdale Business Centre
216-218 Homesdale Rd., Bromley - BR12QZ
http://www.o-hand.com
--
To unsubscribe send a mail to [EMAIL PROTECTED]
