<div dir="ltr"><div>Thanks for the answer,<br></div><div>so actually the stream just needs to be composed, and not rendered.<br></div><div>How could the client app control this composition?<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 25, 2015 at 10:28 AM, Gunnar Sletta <span dir="ltr"><<a href="mailto:gunnar.sletta@jolla.com" target="_blank">gunnar.sletta@jolla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 25 May 2015, at 08:59, Tone Kastlunger <<a href="mailto:users.giulietta@gmail.com">users.giulietta@gmail.com</a>> wrote:<br>
><br>
> Gunnar<br>
><br>
> >You’re greatly cutting down the rendering required per frame by putting the video to an overlay. Just putting it to a window which is composed in lipstick is an improvement. Right now we get the texture, then blend it into the window surface through the scene graph, then send the result to lipstick and render it again there. So the video buffer is drawn as a texture twice before presented to screen.<br>
><br>
> am I understanding correctly this would mean the window would be rendered solely on the lipstick side?<br>
><br>
> Best,<br>
> tk<br>
<br>
</span>The scenario I outline is one where the client application sends the media buffer directly to lipstick for composition, rather than drawing that as texture locally into its own window surface and then sending that window surface.<br>
<br>
The client application would still need to render its ui and other stuff through the traditional means, of course.<br>
<br>
There are a lot of ifs in there though, so it is just thoughts for now :)<br>
<br>
cheers,<br>
Gunnar<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Fri, May 22, 2015 at 6:21 PM, Gunnar Sletta <<a href="mailto:gunnar.sletta@jolla.com">gunnar.sletta@jolla.com</a>> wrote:<br>
><br>
> > On 22 May 2015, at 14:42, Mohammed Hassan <<a href="mailto:mohammed.hassan@jolla.com">mohammed.hassan@jolla.com</a>> wrote:<br>
> ><br>
> > On Fri, 22 May 2015 16:31:35 +0800<br>
> > Halley <<a href="mailto:halley_zhao@sina.com">halley_zhao@sina.com</a>> wrote:<br>
> ><br>
> >> after  a thought, I think overlay can be added back in the following<br>
> >> way:1. wayland-android-client-protocol.h supports passing<br>
> >> ANativeWindowBuffer from wayland client to server.2. An<br>
> >> object(WindowSurface) with same interface of ANativeWindow can be<br>
> >> constructed in host; which meets the requirement of android codecs.3.<br>
> >> then we can create gst video sink element which accepts<br>
> >> ANativeWindow, gst can feed the WindowSurface to android<br>
> >> codecs.finally weston receives ANativeWindowBuffer from media client,<br>
> >> it has the option to assign this ANativeWindowBuffer to Overlay plane.<br>
> ><br>
> > There is no need to add anything to wayland because all the needed<br>
> > functionality is already there.<br>
> ><br>
> > clients communicate already with the compositor using android native<br>
> > buffers.<br>
> ><br>
> > The only thing we need is:<br>
> > 1) a way to tell the sink to use the overlay<br>
> > 2) a way to tell the compositor to use the overlay for a certain buffer<br>
> > 3) A way to tell the compositor the "position" of rendering (x, y).<br>
> > 4) expose that to Qt in a simple way.<br>
> ><br>
> > #1 is easy to achieve with a simple property<br>
> > #2 is already implemented but I am not entirely sure<br>
><br>
> It is in part at least. The lipstick bits are in place:<br>
><br>
> <a href="https://github.com/nemomobile/lipstick/blob/master/src/compositor/hwcrenderstage.cpp" target="_blank">https://github.com/nemomobile/lipstick/blob/master/src/compositor/hwcrenderstage.cpp</a><br>
> <a href="https://github.com/nemomobile/lipstick/blob/master/src/compositor/lipstickcompositorwindow.cpp#L434" target="_blank">https://github.com/nemomobile/lipstick/blob/master/src/compositor/lipstickcompositorwindow.cpp#L434</a><br>
><br>
> Implementation for the Jolla phone (which is a research project for now) is here:<br>
> <a href="https://github.com/sletta/qt5-qpa-hwcomposer-plugin/tree/sbj-hwcinterface" target="_blank">https://github.com/sletta/qt5-qpa-hwcomposer-plugin/tree/sbj-hwcinterface</a>.<br>
><br>
> > #3 is something that might or might not be there. Or maybe the overlay<br>
> > can only be used for full screen rendering?<br>
><br>
> I’ve always thought that we should have some special QWindow type for media surfaces, that allows for posting the media stream buffers directly to the compositor without any extra composition.<br>
><br>
> > #4 is something I have no idea how to implement.<br>
><br>
> something with QWindow with backing in the platform plugin and in libhybris, I’d say :)<br>
><br>
> ><br>
> > The question still remains: Does using the overlay bring any<br>
> > improvement? Is it really needed?<br>
><br>
> You’re greatly cutting down the rendering required per frame by putting the video to an overlay. Just putting it to a window which is composed in lipstick is an improvement. Right now we get the texture, then blend it into the window surface through the scene graph, then send the result to lipstick and render it again there. So the video buffer is drawn as a texture twice before presented to screen.<br>
><br>
> By having a media surface style QWindow, you would skip the client side composition step done by the scene graph, basically halving the work the GPU needs to do.<br>
><br>
> If the buffer coming in to lipstick was picked up and hardware compositor compatible, we could ditch that step as well, letting the GPU be idle while playing video (assuming no overlay controls or subtitles)<br>
><br>
> You probably wouldn’t notice too much in terms of performance on the phone as we can already do the two GL passes at the framerate of the video, but it should benefit battery for playback quite a bit.<br>
><br>
> cheers,<br>
> Gunnar<br>
><br>
> ><br>
> > Cheers,<br>
> ><br>
> ><br>
> >><br>
> >> --------------------------------<br>
> >><br>
> >><br>
> >> ----- 原始邮件 -----<br>
> >> 发件人：Mohammed Hassan <<a href="mailto:mohammed.hassan@jolla.com">mohammed.hassan@jolla.com</a>><br>
> >> 收件人：Sailfish OS Developers <<a href="mailto:devel@lists.sailfishos.org">devel@lists.sailfishos.org</a>><br>
> >> 主题：Re: [SailfishDevel] 回复：Re: could we<br>
> >> support_hw_overlay_from_gst-droid? 日期：2015年05月19日 21点27分<br>
> >><br>
> >><br>
> >> On Tue, 5 May 2015 23:09:40 +0300<br>
> >> Tone Kastlunger <<a href="mailto:users.giulietta@gmail.com">users.giulietta@gmail.com</a>> wrote:<br>
> >>> Hi;<br>
> >>> apologies for dropping the mailing list - it appears gmail does not<br>
> >>> reply correctly to the mailing list but only to the sender.<br>
> >>> Qt 5.1 was my typo, should have been 5.2.<br>
> >>><br>
> >>> Point being, does lipstic currently handle wayland subsurfaces?<br>
> >> Unfortunately not but it can be done if there is a need ;-)<br>
> >> The point is: Does it really improve the rendering/playback<br>
> >> performance? Cheers,<br>
> >> _______________________________________________<br>
> >> SailfishOS.org Devel mailing list<br>
> >> To unsubscribe, please send a mail to<br>
> >> <a href="mailto:devel-unsubscribe@lists.sailfishos.org">devel-unsubscribe@lists.sailfishos.org</a><br>
> ><br>
> > _______________________________________________<br>
> > SailfishOS.org Devel mailing list<br>
> > To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org">devel-unsubscribe@lists.sailfishos.org</a><br>
><br>
> _______________________________________________<br>
> SailfishOS.org Devel mailing list<br>
> To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org">devel-unsubscribe@lists.sailfishos.org</a><br>
><br>
> _______________________________________________<br>
> SailfishOS.org Devel mailing list<br>
> To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org">devel-unsubscribe@lists.sailfishos.org</a><br>
<br>
_______________________________________________<br>
SailfishOS.org Devel mailing list<br>
To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org">devel-unsubscribe@lists.sailfishos.org</a></div></div></blockquote></div><br></div>