Excerpts from Robert Bragg's message of Mon Jan 11 15:02:36 +0000 2010:
> 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.
er, I mean #5 oops
>
> 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]
