[Qt-interest] Intercepting Phonon VideoWidget frames as theyare pushed

[Richard Moe Gustavsen]

>> I've been unable to "capture" VideoWidget paint events at all -- it
>> appears as if it somehow gets drawn outside of a PaintEvent -- but
>> how
>> could it then be captured and redirected onto a
>> QGraphicsViewProxyWidget?

...

>> Note that my only test case is trying to capture a
>> Phonon::VideoWidget, so I suppose a possibility is that I'm doing the
>> right things, but VideoWidget somehow bypasses normal stuff for
>> performance purposes.  I've been looking through the Phonon backend
>> (Quicktime) code, but it's not apparent how drawing is performed.

To shed some light on your efforts:
How video frames are drawn in the QuickTime backend depends whether or not
you use the carbon or the cocoa port of Qt, and then if you build for 32 bit
or 64 bit, and then if you are inside Graphics View or not. In the end, we
have implemented 7 different approces for drawing (sigh).

If we can, we of course use hardware accelerated drawing of frames. This
means creating OpenGL textures for each frame and draw them inside a
QGLWidget (wich is added as a child inside the VideoWidget). To make this as
efficient and steady as possible (and to maintain the frame rate), we draw
the frame immidiatly when its ready, rather than scheduling paint events
(the code for handling this stuff is done inside videowidget.mm)

When inside Graphics View, we follow the Qt paint engine. This means that we
schedule paint events for each frame, and use a QPainter to draw them the
normal way. To check if a video widget is inside Graphics View, we test if
the videowidgets top-level parent (QWidget::window()) has the
Qt::WA_DontShowOnScreen attribute set. In effect this means that if you
create a parentless videowidget, set this attribute, and call show on it,
you should be able to listen for paintevents, and call functions like
QWidget::render(...). This work-around is internal, so if you play around
with it, bear in mind that it may change without further notice.

-Richard

PS: Webkit uses this trick at the current moment. Take a look at
"MediaPlayerPrivatePhonon.cpp".