One question on wayland desing on buffer

[Carsten Haitzler (The Rasterman)]

On Mon, 02 Sep 2019 08:40:41 +0800 "HalleyZhao" <halleyzhao at 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 - raster at rasterman.com