Optimization idea: soft XvPutImage

[Adam Richter]

On Fri, 9/19/08, Soeren Sandmann <sandmann at daimi.au.dk> wrote:
> Adam Richter <adam_richter2004 at yahoo.com> writes:
> 
> > 	I want to suggest a way we could eliminate a
> substantial
> > amount of data copying [...]
[...]
> Pixman, the software implementation of XRender already has
> support for
> YUV formats, so all that is really required is to just
> export YUV
> picture formats through the XRender protocol. [...]

Thank you for pointing out that pixman has some limited YUV reading support already.  The biggest problem that I see with using the X Render is that it lacks stretch and shrink, at least if I understand correctly from looking at the protocol specification here:

http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob_plain;f=renderproto.txt
See lines 758-766:

Composite

	op:		PICTOP
	src:		PICTURE
	mask:		PICTURE or None
	dst:		PICTURE
	src-x, src-y:	INT16
	mask-x, mask-y:	INT16
	dst-x, dst-y:	INT16
	width, height:	CARD16

The last two parameters (width and height) presumably apply to both source and destination rather than having separate parameters for the source and destination rectangles.

This also appears to be the case when I look in the header for the pixman library  (pixman-0.12/pixman/pixman.h) at the declaration of pixman_blt.  It also only has a width and height, which presumably apply to both source and destination.

Even if you do not want to do stretch, I believe that the X Render extension would require first copying the YUV data to a drawable and then doing a drawable->drawable block transfer operation to do the YUV transformation.  In comparison, XvPutImage is a single call takes an XImage, which can be in shared memory, and would normally be in YUV, and specifies the YUV->RGB conversion and stretch in a single operation.

Thanks for your input, especially the tip about some YUV support already existing in libpixman.

Adam Richter