3 ms·

>> malicious test apps I wrote (using the language of this article, apps which acknowledge the sync request and then take multiple seconds to actually paint, et

>> malicious test apps I wrote (using the language of this article, apps which acknowledge the sync request and then take multiple seconds to actually paint, etc., etc.) This is one area where Wayland should do better. It's the compositors job to resize windows and IMHO draw their decorations. The compositor has a frame to paint and it can't have to wait on applications. Unfortunately some toolkits and DEs have decided that client side decorations should still be a thing. Also with this new partitioning of responsibility is my main annoyance: The DE needs to remember window placement for all my apps, since they are not allowed to know their environment under Wayland (for good reasons).

simcop2387 2y ago
> Also with this new partitioning of responsibility is my main annoyance: The DE needs to remember window placement for all my apps, since they are not allowed to know their environment under Wayland (for good reasons). https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... This might eventually get fixed, above is what I believe is the current proposal for handling this issue and letting apps do some amount of positioning without exposing things that a program shouldn't know about. That said this has had multiple proposals over the past 5-6 years at least and none have managed to make it all the way through. If you go through the previous ones (ext-placement and i forget the others) and ignore the angry messages involved it turns out that it's a very difficult problem to deal with in a way that isn't just a free-for-all with apps either not knowing about monitor placement, or having to handle so much detail about the displays that nothing will ever act consistently. That said, recent discussion on that latest one does look promising so maybe it'll finally happen.
- phkahler 2y ago
  That isn't really what I was hoping for. IMHO it is wasteful for every application to remember its window placement and restore it. Not only does that require additional code in every app, but if there is some kind of policy change there is no way to make it consistent. In other words, at the compositor level one could use the previous position as a default and have an option to do something different if another window is already there. It's simply not the applications job to place itself on the desktop. There are probably use case for such self positioning functionality, but restoring to the last position is not one of them.
  - simcop2387 2y ago
    The application side of it is more for things like the multi-window setup of things like GIMP so that windows that are "docked" next to each other will stay that way past restarts. That's one of the reasons that the newer proposals are doing things with relative positioning between a zone or main window rather than allowing applications to place themselves randomly on whatever monitor or space that they want, interrupting whatever workflow is going on (which actually allows for security issues, i.e. a window pretending to be a password prompt putting itself on top of a browser or something to confuse the user). This also allows for new windows from the application to request that they're positioned next to any others so that related things stay together. This also apparently helps in a few cases where a single "application" to the user is actually multiple separate programs that get run by a main interface. Not as common in new software today but it used to be one of the ways that a lot of older software worked and there's still a decent amount out there apparently that are maintained that way. Keep in mind that this is also a request by the application, not a requirement of the compositor to obey it. If there's not sufficient space where the application requests things then the compositor can just ignore it and do what it believes makes sense.
Arainach 2y ago
>The compositor has a frame to paint and it can't have to wait on applications. This is the source of the visual artifacts this article is trying to prevent, however. Sure, you probably don't want to block resize for multiple seconds, but in general the compositor is very responsive. The app may not be. If you just let the window chrome resize as fast as you get, what do you do with the rest of the window? Leave it transparent? Draw a default black or white area? Both are very ugly and very noticeable in practice. This is the part of the problem space I know the most about - for a number of years I owned window chrome on Windows (don't blame me for the 1px border and way-too-subtle shadows, but after being overruled by PM/design, yes, I was responsible for implementing them). As far as custom decorations - that is a lost battle. Companies and apps want their special design language and will simply not build for your product/operating system/compositor/whatever if you don't give them that kind of support. Twitter and Facebook both want their specific shade of blue and their specific font. Adobe is....well, let's not talk about Adobe. Browser tabs in the title bar are a P0 requirement these days and anyone who doesn't support that will be laughed out of the room. Etc., etc.

simcop2387 2y ago

> Also with this new partitioning of responsibility is my main annoyance: The DE needs to remember window placement for all my apps, since they are not allowed to know their environment under Wayland (for good reasons). https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m... This might eventually get fixed, above is what I believe is the current proposal for handling this issue and letting apps do some amount of positioning without exposing things that a program shouldn't know about. That said this has had multiple proposals over the past 5-6 years at least and none have managed to make it all the way through. If you go through the previous ones (ext-placement and i forget the others) and ignore the angry messages involved it turns out that it's a very difficult problem to deal with in a way that isn't just a free-for-all with apps either not knowing about monitor placement, or having to handle so much detail about the displays that nothing will ever act consistently. That said, recent discussion on that latest one does look promising so maybe it'll finally happen.

phkahler 2y ago
That isn't really what I was hoping for. IMHO it is wasteful for every application to remember its window placement and restore it. Not only does that require additional code in every app, but if there is some kind of policy change there is no way to make it consistent. In other words, at the compositor level one could use the previous position as a default and have an option to do something different if another window is already there. It's simply not the applications job to place itself on the desktop. There are probably use case for such self positioning functionality, but restoring to the last position is not one of them.
- simcop2387 2y ago
  The application side of it is more for things like the multi-window setup of things like GIMP so that windows that are "docked" next to each other will stay that way past restarts. That's one of the reasons that the newer proposals are doing things with relative positioning between a zone or main window rather than allowing applications to place themselves randomly on whatever monitor or space that they want, interrupting whatever workflow is going on (which actually allows for security issues, i.e. a window pretending to be a password prompt putting itself on top of a browser or something to confuse the user). This also allows for new windows from the application to request that they're positioned next to any others so that related things stay together. This also apparently helps in a few cases where a single "application" to the user is actually multiple separate programs that get run by a main interface. Not as common in new software today but it used to be one of the ways that a lot of older software worked and there's still a decent amount out there apparently that are maintained that way. Keep in mind that this is also a request by the application, not a requirement of the compositor to obey it. If there's not sufficient space where the application requests things then the compositor can just ignore it and do what it believes makes sense.

Arainach 2y ago

>The compositor has a frame to paint and it can't have to wait on applications. This is the source of the visual artifacts this article is trying to prevent, however. Sure, you probably don't want to block resize for multiple seconds, but in general the compositor is very responsive. The app may not be. If you just let the window chrome resize as fast as you get, what do you do with the rest of the window? Leave it transparent? Draw a default black or white area? Both are very ugly and very noticeable in practice. This is the part of the problem space I know the most about - for a number of years I owned window chrome on Windows (don't blame me for the 1px border and way-too-subtle shadows, but after being overruled by PM/design, yes, I was responsible for implementing them). As far as custom decorations - that is a lost battle. Companies and apps want their special design language and will simply not build for your product/operating system/compositor/whatever if you don't give them that kind of support. Twitter and Facebook both want their specific shade of blue and their specific font. Adobe is....well, let's not talk about Adobe. Browser tabs in the title bar are a P0 requirement these days and anyone who doesn't support that will be laughed out of the room. Etc., etc.