Excerpts from Jason Tackaberry's message of Tue Jan 05 15:40:16 +0000 2010:
> Hi,
>
> I'm currently using ClutterGLXTexturePixmap to redirect video. Rather
> than having updates from the redirected window be rendered immediately,
> I'd like to instead buffer 4 or 5 frames into separate COGL textures,
> and then replace the underlying COGL texture of a ClutterTexture using
> my own timing mechanism.
>
> >From what I can see, in order to accomplish this, it looks like I'm
> going to be reimplementing most of the tfp code inside clutter in my
> application. I think the basic recipe would look like:
>
> 1. Create a ClutterTexture to hold the video contents and add it to
> the stage.
> 2. XCompositeRedirectWindow() and XCompositeNameWindowPixmap() to
> fetch the pixmap.
> 3. glXCreatePixmap() on the above pixmap to fetch glx_pixmap.
> 4. Create the desired number of buffered frames with
> cogl_texture_new_with_size().
> 5. Upon a damage event, grab an available COGL texture created in
> #4 and glBindTexture(), then glXBindTexImageEXT() on the
> glx_pixmap.
> 6. A separate pipeline responsible for timing the buffered frames
> takes the oldest updated texture from #5 call
> clutter_texture_set_cogl_texture() on the ClutterTexture from
> #1.
>
> Before falling too far down the rabbit hole, I wanted to ask those
> better informed:
>
> 1. Is the above approach at all tenable?
> 2. Is there any way I can still make use ClutterGLXTexturePixmap
> but extend it in some way to accomplish the same goal?
>
Hi Jason,
In principle your outline looks sensible to me, but the alarm bells
really sound at #4 if you want to do the glBindTexture outside of Cogl.
We are already in a bit of a mess with Clutter doing its own GL calls
outside of Cogl (most specifically glBindTexture). We can only support
applications breaking out into raw GL under very constrained conditions.
(ref cogl_{begin,end}_gl and cogl_flush()) Manually binding textures
will very likely not work with future versions of Clutter and Cogl as we
know we need to do a better job of avoiding texture binding costs and
could well end up caching this state in Cogl at some point; possibly
soon as part of Neil's texture atlas work.
I'm currently aiming to implement a CoglTexturePixmap subclass of
CoglTexture (hopefully fairly soon) so we can directly support
texture_from_pixmap in Cogl. This should gives us APIs something like
cogl_texture_new_from_pixmap () and cogl_texture_pixmap_update () which
I *think* might enable you to do what you want without the manual GL
calls. At this point developers can either use ClutterTexture + this
new cogl_texture_pixmap API directly or we'll possibly also add a new
ClutterTexturePixmap actor which will also support the XSHM fallbacks
currently handled by ClutterX11TexturePixmap and deprecate
ClutterX11TexturePixmap and ClutterGLXTexturePixmap which have become
something of a mess to maintain.
If you wanted to take a look at what's involved in this and perhaps even
take a stab at starting I'd like to recommend taking a look a Neil's
more-texture-backends branch (this sort of work should be based of that
branch until it gets merged to master) as it has changes to how
CoglTextures are subclassed, using a vtable instead of the messy switch
statements we currently have and gives an example of adding a new
texture subclass.
Adding a CoglTexturePixmap subclass should be straightforward, and it
sounds like you are familiar with tfp, so implementing the
_new_from_pixmap() and _pixmap_update() APIs should be ok too. The only
awkward bits I can think of a.t.m are that it would be the first piece
of Cogl code to interact with GLX and currently we don't expose public
API for any CoglTexture subclasses. We are slowly migrating the
GLX/EGL/WGL etc window system code down from the Clutter backends to
Cogl, so adding interaction with GLX is ok; I think we just need a
(private for now) mechanism to inform Cogl of the Display that Clutter
is using.
Please keep us informed if you start looking into this so we don't
duplicate effort though and feel free to hassle me (#clutter irc nick =
rib) or Neil Roberts (irc nick = bpeel).
I hope that helps,
kind regards,
- Robert
--
Robert Bragg, Intel Open Source Technology Center
--
To unsubscribe send a mail to [email protected]
