Matthew Allum wrote on 03/07/08 09:06 AM: > How fast are you running the actual timeline ? My guess is its just > CPU/X overhead from both the decoding and constant rebinding of texture > pixmaps (for each frame) that is sucking cycles from the timeline > scheduling. The texture updates probably happen at a higher priority > than the timeline itself due to how they come into clutter (via damage X > events) - that may not be ideal for this kind of case.
I doubt it's overhead, at least the processes themselves use no discernible additional cpu when viewed from top. I still suspect what I speculated on in my followup email: with vsync enabled, clutter can only flip buffers 60 times a second. If ClutterGLXTexturePixmap is immediately painting for each damage event (following updating the texture itself) and I am playing a 60fps video (with a 60Hz display refresh), then it effectively starves any other painting that might need to occur (due to timelines). Cheers, Jason. -- To unsubscribe send a mail to [EMAIL PROTECTED]
