On Tue, 2008-07-01 at 17:56 +0100, Matthew Allum wrote: > We hope to get clutter_texture_set_from_yuv_data() fixed up in some form > for Clutter 0.8. Its the last remaining niggle really. Patches warmly > welcomed.
I do hope to look into it, although it looks like implementing it properly might require some modification to COGL as well. Meanwhile, I'm playing with clutter_texture_set_from_rgb_data(), and I'm finding it to be oddly expensive. Uploading 30fps of 640x480 RGB32 is incurring 17-20% overhead. I'm hoping you might have some insight. Basically I'm comparing two paths for getting video onto a clutter stage: 1. the Xcomposite path using tfp, and 2. the more direct path of uploading RGB frames straight from the video decoder. So far, on my nvidia card at least, option 1 is by a significant margin faster. Path 1: Video player calls XShmPutImage for each YV12 frame, which is redirected using ClutterGLXTexturePixmap. The overhead of this compared to straight unredirected Xv is basically not noticeable for a 640x480 video (when naively instrumenting this by watching top as the video plays :)). Path 2: Implement custom VO driver on player, performing software colorspace conversion writing the converted frame to a shared memory buffer, which buffer is also attached by the separate clutter process. Clutter process calls clutter_texture_set_from_rgb_data() with has_alpha=TRUE, bpp=4, flags=0. Ignoring the software colorspace conversion (which is absorbed by the player process), the overhead for path 2 is 17-20% of a core, which seems to be entirely from uploading the RGB32 data. If I comment that call out, cpu usage of clutter drops to near 0. I expected Path 1 to be a bit faster at least until clutter implemented hardware colorspace conversion for YUV, but I was a bit surprised by this overhead. It's also worth mentioning that tests/test-stage-read-pixels takes up 100% cpu. Is this expected? Are others seeing this too? Again, using an nvidia 7100GS with binary driver 173.14.09. Thanks, Jason. -- To unsubscribe send a mail to [EMAIL PROTECTED]
