Hi; On Tue, 2008-07-08 at 12:15 +0200, Filippo Argiolas wrote: > Il giorno dom, 06/07/2008 alle 22.29 +0100, Matthew Allum ha scritto: > > Hi; > > > > On Sun, 2008-07-06 at 22:26 +0200, Filippo Argiolas wrote: > > > > > > Yup, you're right.. it was so simple! Now let me make some test to see > > > if it solves the black screen issue. > > Fingers crossed! > > Eheh :).. I'm sorry but setting the clutter context as shared doesn't > seem to do the job.. I've tried also to set the gstreamergl xwindow to > the clutter one but still doesn't work :(
Yeah that wont work I dont think (this is what I mean about the gstreamer-gl needing some kind of X target, it wont just render to an arbitrary texture and let the actual rendering be handled externally - i.e by a clutter actor). > I'm pretty sure I'm doing something wrong but I'm not so experienced in > X and glx programming to understand what's going wrong. > > > Yeah, I *think* so - difficult to really say however without seeing the > > code. It would indeed be nice if the gstreamer-gl sink just worked with > > Clutter though afaik it is really orientated to being the single > > renderer targetting a X drawable (its subcalsses the base X thingy > > iirc?) and working around that could be the difficult part. Im no > > gstreamer expert however. > > I've created a git branch so you can take a look at the code if you > want: > > git://people.freedesktop.org/~fargiolas/gst-plugins-gl > > Just pull the "clutter" branch, relevant code is > gst/gl/gstglcluttersink.c and test/examples/cluttertest.c (note that's > still a bit rough because it's just some code I've written to > experiment) Ok will do. > I'm not sure I understand what you mean with "subclassing the X thingy" > but all the X stuff is in gst-libs/gst/gl/gstgldisplay.c, so you can > take a look there too if you want. See my comment above. > I'm a bit discouraged.. Will it be a great bottleneck to retrieve the > pixel data from video memory and create the cluttertexture from that? > something like clutter-gst? Im not sure I follow. You shouldn't need to pull the frame data back and forth between local and texture memory. All gstreamer gl needs to do is populate a supplied texture id with frame images and produce some kind of notification when it updated. A ClutterActor wrapping this can then do the actual redrawing. > > If it can be someway useful to understand the problem, moving the mouse > over the clutter window outputs this: > (tests/examples/cluttertest:6293): Clutter-CRITICAL **: > clutter_id_pool_lookup: assertion `id < id_pool->array->len' failed > Whats in the Clutter window ? If the video output but its not an actual actor then that'll cause that. Everything rendering to the stage needs to be wrapped in a ClutterActor otherwise eventing and other magic wont work. Many thanks; == Matthew -- To unsubscribe send a mail to [EMAIL PROTECTED]
