Current state of Window Decorations

[Pekka Paalanen]

On Thu, 25 Jun 2020 19:01:33 +1000
Brad Robinson <brobinson at toptensoftware.com> wrote:

> That said, what would be the recommended way to implement this - would you
> typically have one surface for the decorations and an embedded sub-surface
> for the content area?  eg: what happens if you use a drawing library
> (cairo/skia whatever) for the decorations but then want to embed opengl
> content for example.

Hi,

while it may be attractive to use one surface for your content and
several (sub-)surfaces for the decorations, I believe it can cause
"seams" to become visible if the compositor is doing anything else than
showing the pixels 1:1, e.g. fractional scaling, zoom, tilted windows (a
gimmick in Weston, freedom to arbitrarily rotate windows). It is hard to
do bilinear sampling across multiple textures, so it is likely the
adjacent edges of two surfaces are not blended perfectly by a
compositor. Whether that actually disturbs users or not depends on what
is being show and how. Maybe it's not a big concern.

If you use one big surface for decorations behind the main content, you
obviously waste the memory in the decorations buffer occluded by the
main content. Hence piecing together decorations from four small
surfaces.

My personal opinion favours blitting decorations into the main surface.
With OpenGL it's not a problem per se, but the toolkit API you expose
might make it difficult if the premise is that the user can own "the
full surface" with OpenGL directly.

If your main content comes from a video decoder or a camera, it may be
best to use sub-surface(s). Blitting into a video frame might not work
too well. Not having to copy the video content is the main intended use
case for sub-surfaces.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200625/45adcfc9/attachment.sig>