--- On Mon, 9/22/08, Michel Dänzer [EMAIL PROTECTED] wrote:
On Sun, 2008-09-21 at 13:58 +0200, Soeren Sandmann wrote:
As other people pointed out, XRender does allow
arbitrary 3x3
transformations of source images, but you are right
that the XRender
protocol would require putting the
On Fri, 9/19/08, Soeren Sandmann [EMAIL PROTECTED] wrote:
Adam Richter [EMAIL PROTECTED] 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
On Sun, Sep 21, 2008 at 11:10 AM, Adam Richter
[EMAIL PROTECTED] wrote:
On Fri, 9/19/08, Soeren Sandmann [EMAIL PROTECTED] wrote:
Adam Richter [EMAIL PROTECTED] writes:
I want to suggest a way we could eliminate a
substantial
amount of data copying [...]
[...]
Pixman, the software
On Sun, Sep 21, 2008 at 02:10:07AM -0700, Adam Richter wrote:
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
Adam Richter [EMAIL PROTECTED] writes:
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
I want to suggest a way we could eliminate a substantial
amount of data copying when playing video on X servers that do not
provide hardware video windows, including servers that offer the X
shared memory extension. In common situations, I suspect that this
could reduce memory bus
On 17.09.2008 14:22, Adam Richter wrote:
2) Many open source drivers lack this YUV/stretch capability
even if the hardware has it, due to lack of public
documentation or slow development in comparison to the
life cycle of the hardware, even though efforts to
