On Mon, 02 Sep 2019 08:40:41 +0800 "HalleyZhao" <halleyz...@sina.com> said:
> Hi experts: wayland designs a light-weight server, usually client manages > buffer by themselves. It gives client more flexibility, migration > rendering/composition between different server, subsurface to keep layout > while keeping view hiarchy. however, there is something not convenient for > wayland server. take android surfaceflinger as counterpart, surfaceflinger > manages the buffer/layer of surface, then any client (owns the BufferQueue > client proxy) can update the surface directly. that is, mediaserver in > android can enqueueBuffer to update the surface directly. in wayland world, a > mediaserver has to pass the buffer (handle) to app/UI process, then the > surface is updated in app process. Is my above understanding correct? Correct. Clients are totally isolated from each other. Client A (media server) can't modify resources or even know client B (video player) exists VIA the compositor. This is both for security and simplicity. This makes Wayland compositors/servers nice and simple. They only deal with the client that owns those surfaces/buffers and can assume that client presents precisely what it wants to have presented. It's a "client problem" to deal with a media server if there is such a thing, take buffers from that media server and then pass them on to the compositor. This makes things like synchronisation much easier as "the client does it" and can either just draw media buffers using opengl or whatever mechanisms itself into a single buffer of it's own, or split them out into subsurfaces and ensure those subsurfaces and other rendered content are syncrhonized correctly. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
