<br><br><div class="gmail_quote">2010/3/26 Zack Rusin <span dir="ltr"><<a href="mailto:zack@kde.org">zack@kde.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Friday 26 March 2010 14:37:26 Aaron J. Seigo wrote:<br>
> On March 26, 2010, Marco Martin wrote:<br>
> > the mediacenter as is now is a -completely- different problem.<br>
> > here we want to display a fullscreen video, with occasionally some chrome<br>
> > over it when we need.<br>
><br>
> yep.<br>
><br>
> > as a "temporary" solution (that will indeed last for years) putting the<br>
> > video on a window behind the mediacenter chrome (and hiding completely<br>
> > the plasma window when not needed) is the less hacky (believe or not :p)<br>
> > more performant and simpler to implement solution<br>
><br>
> i wonder if hiding the plasma window will be the best solution<br>
> (showing/hiding windows can be slower than desired, and then you have to<br>
> time it with animations...)<br>
><br>
> if the plasma window is always there, but the background is painted 100%<br>
> transparent and the QGraphicsWidgets shown are also transparent (or even<br>
> hidden), not only will there be no hide/unhide of the window itself and no<br>
> animation timing coordination needed but you can do all the event handling<br>
> in the Plasma::Containment and/or the widgets on it.<br>
><br>
> the only possible problems i can think of here are:<br>
><br>
> * kwin automatically disabling compositing because there is a full screen<br>
> app running<br>
><br>
> * it won't work without compositing ... to which i say: tough. if the media<br>
> center requires compositing for video but delivers a really good<br>
> experience, then so be it.<br>
<br>
</div>Actually, it's gonna be dependent on what the driver does it won't work very<br>
well in either case.<br>
<br>
The issue is that on most hardware video doesn't go through the rendering<br>
pipeline, meaning the TMUs never actually see the content, hence xcomposite is<br>
completely useless - it just doesn't see the content.<br>
Unfortunately that's going to be the case on most of those media boxes -<br>
backend scalers (overlays) which are used to implement dedicated video<br>
circuitry is cheaper and uses less power than the full pipeline.<br>
<br>
The proper way of doing this stuff (or at least the way I would have done it)<br>
is finishing the phonon::videoframe interface and using this with GL to<br>
decode/render it. This approach will be the fastest and most flexible.<br>
<br>
And if the video goes full screen, then just placing a videowidget that uses<br>
the overlay on top would be nice - overlays use less power than the full<br>
pipeline and have things that are usually a bit hard to do in shaders, like<br>
e.g. motion compensation.<br>
So it's:<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- use textures and the full pipeline if you need to render something else than<br>
video alongside it (phonon::videoframe + gl)<br></blockquote><div> </div><div>Is Phonon::VideoFrame already playable with? At least in the Experimental branch of Phonon?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- use backend scalers if only video is important and you don't need to<br>
composite things on top of it (probably straight up phonon::videowidget on<br>
top)<br>
<div><div></div><div class="h5"><br>
z<br>
_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Alessandro Diaferia<br>KDE Developer<br>KDE e.V. member<br><br>