Re: Current state of Window Decorations

[Hans de Goede]

Hi,

On 6/25/20 11:40 AM, Simon Ser wrote:

On Thursday, June 25, 2020 11:01 AM, Brad Robinson 
 wrote:


As a toolkit developer coming from Windows/OSX this is fairly
shocking. I'm aware of the decoration protocol, but given it's not
supported (and by the sound of it never will be) on some of the major
distros makes it almost worthless.


It's not really about distros, it's mainly about compositors. GNOME
doesn't support it, but many other compositors do (KDE, Sway, and other
wlroots-based compositors).

If you don't know about libdecoration [1], maybe it'll help, but it's
still pretty wip.

[1]: https://gitlab.gnome.org/jadahl/libdecoration


libdecoration is being used to add client-side decoration support to
blender, see:
https://developer.blender.org/D7989?id=25771

So recently it has been actively worked (and become less WIP).
So if you do not want to completely roll client-side decoration
support from scratch, then using libdecoration is likely a good
option.

Regards,

Hans

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[The Rasterman]

On Thu, 25 Jun 2020 17:16:30 +0300 Pekka Paalanen  said:

> On Thu, 25 Jun 2020 19:01:33 +1000
> Brad Robinson  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 - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[Pekka Paalanen]

On Thu, 25 Jun 2020 19:01:33 +1000
Brad Robinson  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


pgpXzxFmK45wR.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[Daniel Stone]

Hi,

On Thu, 25 Jun 2020 at 10:01, Brad Robinson
 wrote:
> As a toolkit developer coming from Windows/OSX this is fairly shocking.  I'm 
> aware of the decoration protocol, but given it's not supported (and by the 
> sound of it never will be) on some of the major distros makes it almost 
> worthless.
>
> Seems odd to offload this responsibility to every toolkit without providing a 
> mechanism to achieve any consistency.  Or... is this just my background in 
> Windows/OSX where consistency in these areas is really encouraged and this 
> just isn't expected on Linux?

Others have said this well, but the big difference is that Windows and
OS X both have complete native toolkits as part of their base
platform. Those toolkits implement widgets, things like titlebars,
IPC, intra-process message handling and signaling,
internationalisation, application lifecycle management, etc etc.
That's not something we have: toolkits are instead an optional and
interchangeable component.

If you use one of the major extant toolkits, then you can reuse all
that functionality. This is why even some of the monoliths like
Chromium reuse toolkits. If you want to create your own toolkit from
scratch and not base on one of the existing ones, then for better or
worse, you get to recreate all the functionality they provide.

Shifting responsibility for window decorations to the compositor
doesn't solve the problem. Yes the compositor would render them for
you, but then you have additional protocols (with all the
synchronisation issues that implies) for the client and compositor to
co-ordinate rendering of the decorations and the content.

Neither is objectively better or worse, it's just a different design
which inherently brings different tradeoffs.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[The Rasterman]

On Thu, 25 Jun 2020 19:01:33 +1000 Brad Robinson 
said:

> Thanks Simon/Pekka,
> 
> As a toolkit developer coming from Windows/OSX this is fairly shocking.
> I'm aware of the decoration protocol, but given it's not supported (and by
> the sound of it never will be) on some of the major distros makes it almost
> worthless.

It's a different world. There isnt a single entity (Microsoft for Windows,
Apple for OSX) telling you how to look, draw and do something. It is fragmented
due to history and that's just something that has to be accepted.

There will always be a very small number of toolkits that have to do this so
the audience to appease here is very small.

> Seems odd to offload this responsibility to every toolkit without providing
> a mechanism to achieve any consistency.  Or... is this just my background
> in Windows/OSX where consistency in these areas is really encouraged and
> this just isn't expected on Linux?

You already gave up consistency with > 1 toolkit. Buttons, scrollbars,
sliders, even font rendering etc. etc. will all vary between them. They all
need separate themes/configuration to even begin to get any consistency and
that's not including behaviour (right click menu in entries, scrollbar and
wheel behaviour e.g. no accel with wheel vs accel, smooth or jump scrolling, and
so on). 

> 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.
> 
> Brad
> 
> On Thu, Jun 25, 2020 at 6:25 PM Pekka Paalanen  wrote:
> 
> > On Thu, 25 Jun 2020 11:57:42 +1000
> > Brad Robinson  wrote:
> >
> > > Hey All,
> > >
> > > What's the current state and/or plans for window decorations with
> > Wayland?
> > >
> > > I just stumbled on this post
> > > <
> > https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/
> > >,
> > > and after reading the comments I've got to say I'm quite shocked that
> > > getting a window to appear on screen with title bars and decorations that
> > > match the rest of the OS appears to be a non-trivial task.
> > >
> > > Am I missing something? Have things changed since that post was written?
> >
> > Hi,
> >
> > I don't think you're missing much.
> >
> > Without specific Wayland extensions saying otherwise, clients either
> > decorate themselves or live without decorations. I believe the state of
> > the art is:
> >
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/master/unstable/xdg-decoration
> >
> > I wouldn't say that the fact that Wayland extensions exist for
> > server-side decorations means that a Wayland client would be right to
> > not implement client-side decorations. Any compositor likely does not
> > implement all the extensions ever defined or even in wayland-protocols
> > repository, so clients should have fallbacks. However, it is up to you
> > as a developer to decide which fallbacks you implement and which you do
> > not. Obviously that will affect your user experience on compositors
> > where the fallback would be necessary but you didn't implement it.
> >
> > Unfortunately we don't have the wayland-protocols adoption website up
> > yet, where you could see which compositors and toolkits support which
> > extensions. Weston does not support the extension, but I would assume
> > some other compositors do.
> >
> > There are good justifications for both client-side and server-side
> > decorations. Which one is better depends on your goals and policies,
> > and what you value more, which is why the question raises so much heat
> > that few people like to talk about it much as it nearly always
> > escalates to a flame war when more people join the discussion.
> >
> > For example, for some, "match the rest of the OS" is a non-goal, and
> > making the app itself look consistent is a goal. For others, it's the
> > opposite. Will the application always look and feel the same no matter
> > in what environment you run it in, or should it change itself according
> > to the environment. How do you make the user feel at home? There is a
> > lot more to it than just decorations.
> >
> >
> > Thanks,
> > pq
> >


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

Re: Current state of Window Decorations

[Simon Ser]

On Thursday, June 25, 2020 11:01 AM, Brad Robinson 
 wrote:

> As a toolkit developer coming from Windows/OSX this is fairly
> shocking. I'm aware of the decoration protocol, but given it's not
> supported (and by the sound of it never will be) on some of the major
> distros makes it almost worthless.  

It's not really about distros, it's mainly about compositors. GNOME
doesn't support it, but many other compositors do (KDE, Sway, and other
wlroots-based compositors).

If you don't know about libdecoration [1], maybe it'll help, but it's
still pretty wip.

[1]: https://gitlab.gnome.org/jadahl/libdecoration
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[David Edmundson]

>would you typically have one surface for the decorations and an embedded
sub-surface for the content area?

For optimisation reasons you would probably do 5 subsurfaces.
top,left,right,bottom, main contents.
And that would allow the mixing of GL and raster as they are different
surfaces.

I believe Qt intend to go this way for their client side decoration
fallback.

David
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[Brad Robinson]

Thanks Simon/Pekka,

As a toolkit developer coming from Windows/OSX this is fairly shocking.
I'm aware of the decoration protocol, but given it's not supported (and by
the sound of it never will be) on some of the major distros makes it almost
worthless.

Seems odd to offload this responsibility to every toolkit without providing
a mechanism to achieve any consistency.  Or... is this just my background
in Windows/OSX where consistency in these areas is really encouraged and
this just isn't expected on Linux?

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.

Brad

On Thu, Jun 25, 2020 at 6:25 PM Pekka Paalanen  wrote:

> On Thu, 25 Jun 2020 11:57:42 +1000
> Brad Robinson  wrote:
>
> > Hey All,
> >
> > What's the current state and/or plans for window decorations with
> Wayland?
> >
> > I just stumbled on this post
> > <
> https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/
> >,
> > and after reading the comments I've got to say I'm quite shocked that
> > getting a window to appear on screen with title bars and decorations that
> > match the rest of the OS appears to be a non-trivial task.
> >
> > Am I missing something? Have things changed since that post was written?
>
> Hi,
>
> I don't think you're missing much.
>
> Without specific Wayland extensions saying otherwise, clients either
> decorate themselves or live without decorations. I believe the state of
> the art is:
>
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/master/unstable/xdg-decoration
>
> I wouldn't say that the fact that Wayland extensions exist for
> server-side decorations means that a Wayland client would be right to
> not implement client-side decorations. Any compositor likely does not
> implement all the extensions ever defined or even in wayland-protocols
> repository, so clients should have fallbacks. However, it is up to you
> as a developer to decide which fallbacks you implement and which you do
> not. Obviously that will affect your user experience on compositors
> where the fallback would be necessary but you didn't implement it.
>
> Unfortunately we don't have the wayland-protocols adoption website up
> yet, where you could see which compositors and toolkits support which
> extensions. Weston does not support the extension, but I would assume
> some other compositors do.
>
> There are good justifications for both client-side and server-side
> decorations. Which one is better depends on your goals and policies,
> and what you value more, which is why the question raises so much heat
> that few people like to talk about it much as it nearly always
> escalates to a flame war when more people join the discussion.
>
> For example, for some, "match the rest of the OS" is a non-goal, and
> making the app itself look consistent is a goal. For others, it's the
> opposite. Will the application always look and feel the same no matter
> in what environment you run it in, or should it change itself according
> to the environment. How do you make the user feel at home? There is a
> lot more to it than just decorations.
>
>
> Thanks,
> pq
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[The Rasterman]

On Thu, 25 Jun 2020 11:57:42 +1000 Brad Robinson 
said:

> Hey All,
> 
> What's the current state and/or plans for window decorations with Wayland?
> 
> I just stumbled on this post
>  >, and after reading the comments I've got to say I'm quite shocked that
> getting a window to appear on screen with title bars and decorations that
> match the rest of the OS appears to be a non-trivial task.
> 
> Am I missing something? Have things changed since that post was written?

That's how it is. Correct. The point is that clients draw their own decorations
and handle events on them to initiate actions (like begin a move or resize or
close/exit etc.).

The position (for Wayland) has always been "that's the job of a toolkit and apps
will 99% of the time not know or care as the toolkit takes care of it". The
major toolkits all do take care of it and do client side decorations, so it's
a solved problem. It's necessary as there is no guarantee that a compositor will
support any server-side decorations. Unfortunately as you are making a toolkit,
this now is part of your problem-set to address.

I was initially not happy with the client side decoration position of Wayland
but I've come around and I think its definitely the better path for both
consistency (frames match the content now rather than clash), simple "every
frame is perfect" handling (otherwise you end up with complex synronization
protocols to sync rendered content of of the frame and content so they match on
every frame) and efficiency (you can get more screen content to live in
hardware layers to have zero-copy/composite updates of application content,
given that hardware layers are often a scarce resource).

I don't think there is much point in the "have decorations match" line of
thought because move a few pixels further into the app and the content is not
going to match anyway, unless you spend a lot of effort trying to match.
Given the fragmented state of toolkits anyway there is fairly little point, so
I would take the direction of "extend your view of the toolkit to also
design/define the titlebar and other border elements, shadows etc. and ensure
all of that can have a consistent matching look with the content of the window
with some simpler external control points to do things like perhaps select a
base and hilight etc. color if possible so you can later color-match at least".

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

Re: Current state of Window Decorations

[Pekka Paalanen]

On Thu, 25 Jun 2020 11:57:42 +1000
Brad Robinson  wrote:

> Hey All,
> 
> What's the current state and/or plans for window decorations with Wayland?
> 
> I just stumbled on this post
> ,
> and after reading the comments I've got to say I'm quite shocked that
> getting a window to appear on screen with title bars and decorations that
> match the rest of the OS appears to be a non-trivial task.
> 
> Am I missing something? Have things changed since that post was written?

Hi,

I don't think you're missing much.

Without specific Wayland extensions saying otherwise, clients either
decorate themselves or live without decorations. I believe the state of
the art is:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/master/unstable/xdg-decoration

I wouldn't say that the fact that Wayland extensions exist for
server-side decorations means that a Wayland client would be right to
not implement client-side decorations. Any compositor likely does not
implement all the extensions ever defined or even in wayland-protocols
repository, so clients should have fallbacks. However, it is up to you
as a developer to decide which fallbacks you implement and which you do
not. Obviously that will affect your user experience on compositors
where the fallback would be necessary but you didn't implement it.

Unfortunately we don't have the wayland-protocols adoption website up
yet, where you could see which compositors and toolkits support which
extensions. Weston does not support the extension, but I would assume
some other compositors do.

There are good justifications for both client-side and server-side
decorations. Which one is better depends on your goals and policies,
and what you value more, which is why the question raises so much heat
that few people like to talk about it much as it nearly always
escalates to a flame war when more people join the discussion.

For example, for some, "match the rest of the OS" is a non-goal, and
making the app itself look consistent is a goal. For others, it's the
opposite. Will the application always look and feel the same no matter
in what environment you run it in, or should it change itself according
to the environment. How do you make the user feel at home? There is a
lot more to it than just decorations.


Thanks,
pq


pgpU4gzxotsNt.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Current state of Window Decorations

[Simon Ser]

Hi,

On Thursday, June 25, 2020 3:57 AM, Brad Robinson 
 wrote:

> What's the current state and/or plans for window decorations with Wayland?

You'll always need a fallback, but the standard xdg-decoration [1]
protocol lets clients request to be decorated by the compositor.

Simon

[1]: 
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel