[SailfishDevel] 回复：Re: 回复：Re: could we support_hw_overlay_from_gst-droid?
halley_zhao at sina.com
Sat May 9 02:14:08 UTC 2015
I don't have much idea on it as well.
I think EGLImage or texture id are concept inside one process, not able to shared between two process (wayland client and wayland server). for EGL application, drm buffer name is passed by wayland-drm protocol inside libEGL.
some global buffer handle are required to share the buffer directly from app to weston. like gralloc handle, dma_buf, or drm name.
----- 原始邮件 -----
发件人：Mohammed Hassan <mohammed.hassan at jollamobile.com>
收件人：Tone Kastlunger <users.giulietta at gmail.com>
抄送人：Sailfish OS Developers <devel at lists.sailfishos.org>
主题：Re: [SailfishDevel] 回复：Re: could we support_hw_overlay_from_gst-droid?
On Fri, May 01, 2015 at 08:01:34PM +0300, Tone Kastlunger wrote:
> I'd guess this would require patching lipstick (compositor) as well?
I cannot tell. One option is to use wayland subsurfaces (I don't know if it's
even possible or not). We can then extend droideglsink to use subsurfaces
and let the compositor do the work.
I would not prefer giving the buffers themselves to the app for rendering because:
1) There is no guarantee that the content of the buffers will be cross platform. We get
a vendor specific data format encapsulated within an android buffer and we do not
even know (from a programming POV) what the format of the data is
2) If the app blocks, the decoding pipeline will stall. We can push up to 2 buffers only
to the app and if we don't get them back to the decoder we will block and stop decoding.
2 is what we are limiting ourselves to currently but could increase in the future.
An alternate way is to patch glimagesink from plugins-bad to grok our buffers
or to enable waylandsink and ship it.
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfishos.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel