Thanks Oliver. You are right, for opaque, it is top to bottom. And
transparent is reverse.
For the opaque window, I noticed that it calls XRenderComposite with
PictOpSrc. If I understand this correctly, this means only the source
picture ( dclient->picture ) will be written into the dest window. So for
the opaque top to bottom, only the bottommost window will be drawn? It is
weird.
XRenderComposite(wm->xdpy, PictOpSrc, dclient->picture, None,
priv->root_buffer, 0, 0, 0, 0, geom.x, geom.y,
geom.width,
geom.height);
Olivier Fourdan <[email protected]> 于2020年7月10日周五 下午5:12写道：
> Hi,
>
> It actually renders the screen in two passes.
>
> First pass from top to bottom, rendering only the opaque regions, while
> adding up each opaque region to a global clipping region.
>
> Second pass, from bottom to top, rendering only the translucent areas,
> clipping out the opaque regions that it found in the first pass.
>
> That's more efficient than rendering in a single pass from bottom to top.
>
> FWIW, the logic is from xcompmgr, from Keith.
>
> Cheers
> Olivier
>
>
> On Fri, Jul 10, 2020 at 11:06 AM 徐星 <[email protected]> wrote:
>
>>
>> Hi,
>>
>> Do you have any ideas why matchbox window manager render clients from
>> top(near) to bottom(far)? I understand that the painter algorithm
>> requires paints from far to near.
>>
>>
>>
>>
>> https://git.yoctoproject.org/cgit/cgit.cgi/matchbox-window-manager-2/tree/matchbox/comp-mgr/mb-wm-comp-mgr-xrender.c#n1619
>> --
>> NaCl!
>> _______________________________________________
>> [email protected]: X.Org development
>> Archives: http://lists.x.org/archives/xorg-devel
>> Info: https://lists.x.org/mailman/listinfo/xorg-devel
>>
>
--
NaCl!
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
