I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function to XvMC. I have implemented this in NVIDIA's binary drivers and am able to do full framerate HDTV video textures on the higher end GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer contents into a texture.
This shoulds like a good candidate for a GLX extension. I've been wondering when someone would suggest somthing like this. :) Although, I did expect it to come from someone doing video capture work first.
Over the years there have been a couple extensions for doing things this, both from SGI. They both work by streaming video data into a new type of GLX drawable and use that to source pixel / texel data.
http://oss.sgi.com/projects/ogl-sample/registry/SGIX/video_source.txt http://oss.sgi.com/projects/ogl-sample/registry/SGIX/dmbuffer.txt
The function that you're suggesting here is a clear break from that. I don't think that's a bad thing. I suspect that you designed it this way so that the implementation would not have to live in the GLX subsystem or in the 3D driver, correct?
With slightly closer integration between XvMC and the 3D driver, we ought to be able to do something along those lines. Basically, bind a XvMCSurface to a pbuffer. Then, each time a new frame of video is rendered the pbuffer would be automatically updated. Given the way the XvMC works, I'm not sure how well that would work, though. I'll have to think on it some more.
Status XvMCCopySurfaceToGLXPbuffer ( Display *display, XvMCSurface *surface, XID pbuffer_id, short src_x, short src_y, unsigned short width, unsigned short height, short dst_x, short dst_y, int flags );
One quick comment. Don't use 'short', use 'int'. On every existing and future platform that we're likely to care about the shorts will take up as much space as an int on the stack anyway, and slower / larger / more instructions will need to be used to access them.
This function copies the rectangle specified by src_x, src_y, width,
and height from the XvMCSurface denoted by "surface" to offset dst_x, dst_y within the pbuffer identified by its GLXPbuffer XID "pbuffer_id".
Note that while the src_x, src_y are in XvMC's standard left-handed
coordinate system and specify the upper left hand corner of the
rectangle, dst_x and dst_y are in OpenGL's right-handed coordinate system and denote the lower left hand corner of the destination rectangle in the pbuffer.
This conceptually concerns me. Mixing coordinate systems is usually a bad call, and is likely to confuse developers. I assume this means that the image is implicitly inverted? Hmm...
"Flags" may be XVMC_TOP_FIELD, XVMC_BOTTOM_FIELD or XVMC_FRAME_PICTURE.
If flags is not XVMC_FRAME_PICTURE, the src_y and height are in field
coordinates, not frame. That is, the total copyable height is half
the height of the XvMCSurface.
XvMCCopySurfaceToGLXPbuffer does not return until the copy to the
pbuffer has completed. XvMCCopySurfaceToGLXPbuffer is pipelined
with XvMCRenderSurface so no explicit synchronization between XvMCRenderSurface and XvMCCopySurfaceToGLXPbuffer is needed.
The pbuffer must be of type GLX_RGBA, and the destination of the
copy is the left front buffer of the pbuffer. Success is returned
if no error occured, the error code is returned otherwise.
This goes against common practice. The copy should obey the setting of glDrawBuffer. I assume you must have had some reason for doing this...I just can't imagine what it was. :)
Possible Errors:
XvMCBadSurface - The surface is invalid.
BadDrawable - The pbuffer_id is not a valid pbuffer.
BadMatch - The pbuffer is not of type GLX_RGBA or the pbuffer does not have a front left buffer.
XvMCCopySurfaceToGLXPbuffer is supported if the following flag:
#define XVMC_COPY_TO_PBUFFER 0x00000010
is set in the XvMCSurfaceInfo's flags field.
I'd like to bump the API version up to 1.1 and add this. Comments?
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
