[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Phonon::VideoWidget embedded inside a QGraphicsProxyWidget
From: Alessandro Diaferia <alediaferia () gmail ! com>
Date: 2010-03-26 19:32:37
Message-ID: k2l65627f3a1003261232u8814b1e7y88e3d3c453c3de2e () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
2010/3/26 Zack Rusin <zack@kde.org>
> On Friday 26 March 2010 14:37:26 Aaron J. Seigo wrote:
> > On March 26, 2010, Marco Martin wrote:
> > > the mediacenter as is now is a -completely- different problem.
> > > here we want to display a fullscreen video, with occasionally some
> chrome
> > > over it when we need.
> >
> > yep.
> >
> > > as a "temporary" solution (that will indeed last for years) putting the
> > > video on a window behind the mediacenter chrome (and hiding completely
> > > the plasma window when not needed) is the less hacky (believe or not
> :p)
> > > more performant and simpler to implement solution
> >
> > i wonder if hiding the plasma window will be the best solution
> > (showing/hiding windows can be slower than desired, and then you have to
> > time it with animations...)
> >
> > if the plasma window is always there, but the background is painted 100%
> > transparent and the QGraphicsWidgets shown are also transparent (or even
> > hidden), not only will there be no hide/unhide of the window itself and
> no
> > animation timing coordination needed but you can do all the event
> handling
> > in the Plasma::Containment and/or the widgets on it.
> >
> > the only possible problems i can think of here are:
> >
> > * kwin automatically disabling compositing because there is a full screen
> > app running
> >
> > * it won't work without compositing ... to which i say: tough. if the
> media
> > center requires compositing for video but delivers a really good
> > experience, then so be it.
>
> Actually, it's gonna be dependent on what the driver does it won't work
> very
> well in either case.
>
> The issue is that on most hardware video doesn't go through the rendering
> pipeline, meaning the TMUs never actually see the content, hence xcomposite
> is
> completely useless - it just doesn't see the content.
> Unfortunately that's going to be the case on most of those media boxes -
> backend scalers (overlays) which are used to implement dedicated video
> circuitry is cheaper and uses less power than the full pipeline.
>
> The proper way of doing this stuff (or at least the way I would have done
> it)
> is finishing the phonon::videoframe interface and using this with GL to
> decode/render it. This approach will be the fastest and most flexible.
>
> And if the video goes full screen, then just placing a videowidget that
> uses
> the overlay on top would be nice - overlays use less power than the full
> pipeline and have things that are usually a bit hard to do in shaders, like
> e.g. motion compensation.
> So it's:
>
> - use textures and the full pipeline if you need to render something else
> than
> video alongside it (phonon::videoframe + gl)
>
Is Phonon::VideoFrame already playable with? At least in the Experimental
branch of Phonon?
> - use backend scalers if only video is important and you don't need to
> composite things on top of it (probably straight up phonon::videowidget on
> top)
>
> z
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
--
Alessandro Diaferia
KDE Developer
KDE e.V. member
[Attachment #5 (text/html)]
<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>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic