Current state of Window Decorations

[Carsten Haitzler (The Rasterman)]

On Thu, 25 Jun 2020 17:16:30 +0300 Pekka Paalanen <ppaalanen at gmail.com> said:

> 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.

well.. in this case to do this right the compositor is forced to first
pre-render all the subsurfaces to an fbo (for example) THEN take that FBO and do
whatever scaling/stretching/manipulation to it. so it is possible to get it
right on the compositor side, but it'll basically make things less efficient
than the client-side doing this already and handling buffer age for partial
updates right which means most of the time it'll never update the frame areas
anyway.

> 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


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com