<p>it's better the compositor decides whether/how to assign video buffer to overlay plane, like how surfaceflinger does.</p><p>then app needn't care about details (how to set overlay, how to specify position, how to poke the video hole).</p><p><br></p><br><br><div id="">--------------------------------<br></div><div id=""><br></div><br><div id="origbody"><div style="background: #f2f2f2;">----- 原始邮件 -----<br>发件人：Mohammed Hassan <mohammed.hassan@jolla.com><br>收件人：Sailfish OS Developers <devel@lists.sailfishos.org><br>主题：Re: [SailfishDevel] 回复：Re:  回复：Re: could_we_support_hw_overlay_from_gst-droid?<br>日期：2015年05月22日 20点42分<br></div><br>On Fri, 22 May 2015 16:31:35 +0800<br>Halley <halley_zhao@sina.com> wrote:<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>There is no need to add anything to wayland because all the needed<br>functionality is already there.<br>clients communicate already with the compositor using android native<br>buffers.<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>#1 is easy to achieve with a simple property<br>#2 is already implemented but I am not entirely sure<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>#4 is something I have no idea how to implement.<br>The question still remains: Does using the overlay bring any<br>improvement? Is it really needed?<br>Cheers,<br>> <br>> --------------------------------<br>> <br>> <br>> ----- 原始邮件 -----<br>> 发件人：Mohammed Hassan <mohammed.hassan@jolla.com><br>> 收件人：Sailfish OS Developers <devel@lists.sailfishos.org><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 <users.giulietta@gmail.com> 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>> devel-unsubscribe@lists.sailfishos.org<br>_______________________________________________<br>SailfishOS.org Devel mailing list<br>To unsubscribe, please send a mail to devel-unsubscribe@lists.sailfishos.org</div>