9 ms·

X11 was the only environment that did server side decorations. Both win32 and macos draw decorations client-side. Even if you don't handle the respective messa

X11 was the only environment that did server side decorations. Both win32 and macos draw decorations client-side. Even if you don't handle the respective messages in your event loop, the libraries that you linked to, do. Server-side decorations are hard. You cannot properly synchronize two processes to draw perfect frame. When a single process is responsible, it is easy.

jstimpfle 4y ago
> You cannot properly synchronize two processes to draw perfect frame. Not taking sides, but why do you need to synchronize two processes when one should only draw a frame and the other should only draw the contents?
- fvdessen 4y ago
  When you resize the window, both the frame and the content should be resized and rendered at the same time, otherwise you have gaps or clipped content
  - jstimpfle 4y ago
    There could be the same problem outside of a window given that most windows are rendered by separate processes. Unless there is a compositor, which I think there is? And can that problem you mention not be avoided using a compositor?
  - kaba0 4y ago
    I don’t know, if I resize the window I do want the border to reflect the changes even if the app froze, and drawing a black rectangle with a frame and optionally drawing the ready frame made by the app onto it doesn’t sound too hard to me.
    - dzaima 4y ago
      Most of the time, though, you run applications that aren't frozen. Sure, having resizing do something in that case is useful, but you don't want those black bars to appear for the fraction of time between moving your mouse & the application redrawing, for every single frame of window resizing where the app didn't redraw in time (text reflowing, graphics initialization & other re-computation can often push resizing frame times above the 16ms of 60fps). (X11 and its server-side decorations appear to be able to handle this as-is - decoration redrawing is delayed until either the application redraws, or some timeout (iirc around a second or two?), at which point you get the ugly black bars)
  - chrismorgan 4y ago
    Good reading on this issue: https://raphlinus.github.io/rust/gui/2019/06/21/smooth-resize-test.html https://raphlinus.github.io/rust/gui/2019/06/21/smooth-resiz...
  - badsectoracula 4y ago
    This sounds like Wayland Weirdness. On Xorg with Window Maker and no (desktop) compositor running, my own toolkit (example app[0]) resizes instantly. On Xorg with KDE5 (not sure which exactly version, whatever openSUSE has) and a (desktop) compositor enabled, same toolkit also resizes without gaps (though there is a small delay, probably due to the compositor, i didn't try without it). Same with native apps. On Wayland/KDE5 the same toolkit resizes without gaps but there is a visible "lag" for the titlebar to be updated that didn't exist with Xorg/KDE5. Since the toolkit only supports X11 i'm not sure if it is due to XWayland or KDE5 though. TBH in none of the above configurations that'd be something i'd notice unless i was looking for it - or it was very laggy. Even on Wayland, it is something i noticed because i was resizing the window constantly back and forth to see if there is any lag. [0] https://i.imgur.com/00Y3kZi.png https://i.imgur.com/00Y3kZi.png
    - gapan 4y ago
      Wait. Your own toolkit? Link please?
      - badsectoracula 4y ago
        http://runtimeterror.com/tech/lforms/ http://runtimeterror.com/tech/lforms/ However i didn't link to it intentionally since this site contains a three year old code dump and my current version has a lot of things changed in an incompatible way, so i wouldn't like people using it just yet. I still need to do a bunch of other changes to the API as well as fix some stuff and rethink how some other things work that can be hard to change later if i decide to make a proper release that people can depend on (e.g. i'd like to change how fonts work to allow for arbitrary font styles). I don't have much time for it right now though, but perhaps in a few months i'll be able to allocate some time for it.
  - account42 4y ago
    So make the compositor use the size of the buffer the window supplied when rendering the decorations (or at least allow the old size for a frame or so). Next problem.
sph 4y ago
> Both win32 and macos draw decorations client-side. That's technically true but misleading. Yes, they have client-side decorations, but also a single and unified UI toolkit all applications use. So effectively _you_, the application writer, do not have to care about decorations. Whereas, on Linux Wayland, if you want to support GNOME, _you_ have to care about decorations, or you have no titlebar nor X button. Which means you need to link against libdecor yourself to get that functionality and in theory wouldn't be that bad if that library was maintained and functional, but it isn't. The one stable tag is 0.1.0 from one year ago, and it still causes massive lag when trying to resize a window if you have more than 1x scaling: https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 — Don't be mislead by the title, affects AMD as well. libdecor is the _only_ way to have decorations on Wayland on all major DEs, unless you actually want to write the entire decoration code yourself. And it's buggy and unmaintained. And, cherry on top, libdecor does not match the desktop environment's look and feel, so your app has decorations that look completely out of place. I'm a GNOME and Wayland apologist, but libdecor is terrible, unavoidable, and exists only because GNOME couldn't pull their head out of their arse and created this situation. Not supporting server-side decorations is only a good idea in a vacuum, not in the real world. Applications should be able to choose whether they care about it (i.e. Firefox for their UI), or not at all (i.e. a video game window), as it's possible to do in Windows or macOS.
- PlutoIsAPlanet 4y ago
  > Whereas, on Linux Wayland, if you want to support GNOME If you want to support GNOME, you use GTK or use a library that interfaces with GTK. The binary compatibility with other desktops is just a "nice thing" to have, but GNOME really doesn't care for apps not made for GNOME. There was a project where Qt would interface with GTK and let GTK handle its window management (similar to macOS/Windows), rather than dealing directly to the display server, but I think its dead.
  - chrismorgan 4y ago
    > but GNOME really doesn't care for apps not made for GNOME And this is the sabotage of GTK and the Linux desktop that I’m speaking of.
garaetjjte 4y ago
>win32 Are you sure about this? How would things like appending "Not responding" to title bar work?
- PlutoIsAPlanet 4y ago
  It's a separate event loop from your application.
  - account42 4y ago
    Or in other terms, a hack to work around the limitations of CSDs which MS is stuck with. We don't need to copy their mistakes.
chrismorgan 4y ago
I think you may be trying to draw a technical distinction which misses the point of what people mean by “client-side decorations” and “server-side decorations”. Win32 has always defaulted to server-side decorations, by which we mean that the window manager controls the rendering, appearance and functionality of the title bar. Maybe this is actually run in client space via user32.dll or whatever as part of the OS-managed event loop, but functionally your app gets told “here, have a client area” (and isn’t that name telling!) and works inside that and completely ignores the remainder of the window area, and the window decorations implementation is provided by the window manager, so that theme changes (ancient Classic, XP Luna, recent Classic, Aero Glass, Modern, colours within each, &c. &c.) immediately apply globally. This is what people mean by server-side decorations. They mean what is still the default under Win32 and I presume macOS, even if on both platforms it’s not the recommended style any more for most apps. But it’s also worth noting that the recommended client-side decorations style on Win32 at least (don’t know much about macOS) is still guided by window manager stylistic conventions, including theme colours where possible.
- PlutoIsAPlanet 4y ago
  Two different things here. In the Wayland/Xorg world, server-side decorations means its drawn by the compositor or display server, neither macOS or Windows do this. Windows is a lot more complicated, the decorations are drawn by the client... but that client is part of the userspace dll from the system you link to in your app and gives you a handle to draw on. macOS the only documented method to draw afaik is through Cocoa which can give you a space to draw on, but the linked Cocoa library will still draw your apps window. To the user, I guess SSD achieve the same thing as Windows/macOS do, but with very different methods because unlike macOS and Windows, there's no central toolkit/library.
flohofwoe 4y ago
Huh? When I create a window on macOS, Windows or X11, I get a decorated window, and that's the only point that matters. Where this decoration is drawn within the operating system's window system is nothing the API user needs to or should worry about.
phkahler 4y ago
Most user interactions with window decorations need to be handled server-side. Server side also makes sense because the compositor and the DE are basically the same under Wayland, so things like themes should be implemented once server-side and applications wouldn't have to do anything to change their frame to match.
LtWorf 4y ago
> X11 was the only environment that did server side decorations. > Both win32 and macos draw decorations client-side Which is why on linux if a process freezes I can kill it by pressing the normal X on the window, while on other operating systems I need to open the process manager.
- AshamedCaptain 4y ago
  And you'll also note that if a win32 process freezes (i.e. stops replying to wm messages in a timely fashion), the win32 window manager will take over drawing the window decoration, so that you can also kill the process by pressing the normal X close button on the window. At least since XP times.
  - account42 4y ago
    Right, which makes using the bUt wInDowS UsEs CsDS argument against SSDs especially silly. Even MS found that CSDs have usability problems but are stuck with them so have to hack around the limitations - and even then there will still be a time where you can't even move the window before the SSD hack takes over.
- deleted 4y ago
  [deleted]
yxhuvud 4y ago
It is easy until you have to support the look and feel of two different server side environments.
marcodiego 4y ago
I remember an old post years ago on DOSBox forum. Someone posted a patch to update the number of FPS on the window titlebar. Someone else tried it came back complaining that it ate the processor. A bit of investigation revealed how expensive it was to update the titlebar: DOSBox, in some form, notified the DE (window manager) that the titlebar needed update; then the window manager informed the window decorator about the update; it then updated the titlebar and notified X11 to redraw it; X11 then had to sync all that to post new screen with everything ready to show. Now, go back and count the number of processes and calculate how many context switches were required just to update the titlebar. Server-side decoration made things more modular because it allowed the window decorator to be an entirely independent process. It could allow to use Beryl or kwin or any other window decorator with compiz, for example. Even considering these advantages, the price one paid for it was too expensive to justify. X11 did it, basically nobody else did; certainly for a good reason. Server-side decoration is one thing I'm glad we are finally getting rid of.

jstimpfle 4y ago

> You cannot properly synchronize two processes to draw perfect frame. Not taking sides, but why do you need to synchronize two processes when one should only draw a frame and the other should only draw the contents?

fvdessen 4y ago
When you resize the window, both the frame and the content should be resized and rendered at the same time, otherwise you have gaps or clipped content
- jstimpfle 4y ago
  There could be the same problem outside of a window given that most windows are rendered by separate processes. Unless there is a compositor, which I think there is? And can that problem you mention not be avoided using a compositor?
- kaba0 4y ago
  I don’t know, if I resize the window I do want the border to reflect the changes even if the app froze, and drawing a black rectangle with a frame and optionally drawing the ready frame made by the app onto it doesn’t sound too hard to me.
  - dzaima 4y ago
    Most of the time, though, you run applications that aren't frozen. Sure, having resizing do something in that case is useful, but you don't want those black bars to appear for the fraction of time between moving your mouse & the application redrawing, for every single frame of window resizing where the app didn't redraw in time (text reflowing, graphics initialization & other re-computation can often push resizing frame times above the 16ms of 60fps). (X11 and its server-side decorations appear to be able to handle this as-is - decoration redrawing is delayed until either the application redraws, or some timeout (iirc around a second or two?), at which point you get the ugly black bars)
- chrismorgan 4y ago
  Good reading on this issue: https://raphlinus.github.io/rust/gui/2019/06/21/smooth-resize-test.html https://raphlinus.github.io/rust/gui/2019/06/21/smooth-resiz...
- badsectoracula 4y ago
  This sounds like Wayland Weirdness. On Xorg with Window Maker and no (desktop) compositor running, my own toolkit (example app[0]) resizes instantly. On Xorg with KDE5 (not sure which exactly version, whatever openSUSE has) and a (desktop) compositor enabled, same toolkit also resizes without gaps (though there is a small delay, probably due to the compositor, i didn't try without it). Same with native apps. On Wayland/KDE5 the same toolkit resizes without gaps but there is a visible "lag" for the titlebar to be updated that didn't exist with Xorg/KDE5. Since the toolkit only supports X11 i'm not sure if it is due to XWayland or KDE5 though. TBH in none of the above configurations that'd be something i'd notice unless i was looking for it - or it was very laggy. Even on Wayland, it is something i noticed because i was resizing the window constantly back and forth to see if there is any lag. [0] https://i.imgur.com/00Y3kZi.png https://i.imgur.com/00Y3kZi.png
  - gapan 4y ago
    Wait. Your own toolkit? Link please?
    - badsectoracula 4y ago
      http://runtimeterror.com/tech/lforms/ http://runtimeterror.com/tech/lforms/ However i didn't link to it intentionally since this site contains a three year old code dump and my current version has a lot of things changed in an incompatible way, so i wouldn't like people using it just yet. I still need to do a bunch of other changes to the API as well as fix some stuff and rethink how some other things work that can be hard to change later if i decide to make a proper release that people can depend on (e.g. i'd like to change how fonts work to allow for arbitrary font styles). I don't have much time for it right now though, but perhaps in a few months i'll be able to allocate some time for it.
- account42 4y ago
  So make the compositor use the size of the buffer the window supplied when rendering the decorations (or at least allow the old size for a frame or so). Next problem.

sph 4y ago

> Both win32 and macos draw decorations client-side. That's technically true but misleading. Yes, they have client-side decorations, but also a single and unified UI toolkit all applications use. So effectively _you_, the application writer, do not have to care about decorations. Whereas, on Linux Wayland, if you want to support GNOME, _you_ have to care about decorations, or you have no titlebar nor X button. Which means you need to link against libdecor yourself to get that functionality and in theory wouldn't be that bad if that library was maintained and functional, but it isn't. The one stable tag is 0.1.0 from one year ago, and it still causes massive lag when trying to resize a window if you have more than 1x scaling: https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 https://gitlab.gnome.org/jadahl/libdecor/-/issues/37 — Don't be mislead by the title, affects AMD as well. libdecor is the _only_ way to have decorations on Wayland on all major DEs, unless you actually want to write the entire decoration code yourself. And it's buggy and unmaintained. And, cherry on top, libdecor does not match the desktop environment's look and feel, so your app has decorations that look completely out of place. I'm a GNOME and Wayland apologist, but libdecor is terrible, unavoidable, and exists only because GNOME couldn't pull their head out of their arse and created this situation. Not supporting server-side decorations is only a good idea in a vacuum, not in the real world. Applications should be able to choose whether they care about it (i.e. Firefox for their UI), or not at all (i.e. a video game window), as it's possible to do in Windows or macOS.

PlutoIsAPlanet 4y ago
> Whereas, on Linux Wayland, if you want to support GNOME If you want to support GNOME, you use GTK or use a library that interfaces with GTK. The binary compatibility with other desktops is just a "nice thing" to have, but GNOME really doesn't care for apps not made for GNOME. There was a project where Qt would interface with GTK and let GTK handle its window management (similar to macOS/Windows), rather than dealing directly to the display server, but I think its dead.
- chrismorgan 4y ago
  > but GNOME really doesn't care for apps not made for GNOME And this is the sabotage of GTK and the Linux desktop that I’m speaking of.

garaetjjte 4y ago

>win32 Are you sure about this? How would things like appending "Not responding" to title bar work?

PlutoIsAPlanet 4y ago
It's a separate event loop from your application.
- account42 4y ago
  Or in other terms, a hack to work around the limitations of CSDs which MS is stuck with. We don't need to copy their mistakes.

chrismorgan 4y ago

I think you may be trying to draw a technical distinction which misses the point of what people mean by “client-side decorations” and “server-side decorations”. Win32 has always defaulted to server-side decorations, by which we mean that the window manager controls the rendering, appearance and functionality of the title bar. Maybe this is actually run in client space via user32.dll or whatever as part of the OS-managed event loop, but functionally your app gets told “here, have a client area” (and isn’t that name telling!) and works inside that and completely ignores the remainder of the window area, and the window decorations implementation is provided by the window manager, so that theme changes (ancient Classic, XP Luna, recent Classic, Aero Glass, Modern, colours within each, &c. &c.) immediately apply globally. This is what people mean by server-side decorations. They mean what is still the default under Win32 and I presume macOS, even if on both platforms it’s not the recommended style any more for most apps. But it’s also worth noting that the recommended client-side decorations style on Win32 at least (don’t know much about macOS) is still guided by window manager stylistic conventions, including theme colours where possible.

PlutoIsAPlanet 4y ago
Two different things here. In the Wayland/Xorg world, server-side decorations means its drawn by the compositor or display server, neither macOS or Windows do this. Windows is a lot more complicated, the decorations are drawn by the client... but that client is part of the userspace dll from the system you link to in your app and gives you a handle to draw on. macOS the only documented method to draw afaik is through Cocoa which can give you a space to draw on, but the linked Cocoa library will still draw your apps window. To the user, I guess SSD achieve the same thing as Windows/macOS do, but with very different methods because unlike macOS and Windows, there's no central toolkit/library.

flohofwoe 4y ago

Huh? When I create a window on macOS, Windows or X11, I get a decorated window, and that's the only point that matters. Where this decoration is drawn within the operating system's window system is nothing the API user needs to or should worry about.

phkahler 4y ago

Most user interactions with window decorations need to be handled server-side. Server side also makes sense because the compositor and the DE are basically the same under Wayland, so things like themes should be implemented once server-side and applications wouldn't have to do anything to change their frame to match.

LtWorf 4y ago

> X11 was the only environment that did server side decorations. > Both win32 and macos draw decorations client-side Which is why on linux if a process freezes I can kill it by pressing the normal X on the window, while on other operating systems I need to open the process manager.

AshamedCaptain 4y ago
And you'll also note that if a win32 process freezes (i.e. stops replying to wm messages in a timely fashion), the win32 window manager will take over drawing the window decoration, so that you can also kill the process by pressing the normal X close button on the window. At least since XP times.
- account42 4y ago
  Right, which makes using the bUt wInDowS UsEs CsDS argument against SSDs especially silly. Even MS found that CSDs have usability problems but are stuck with them so have to hack around the limitations - and even then there will still be a time where you can't even move the window before the SSD hack takes over.
deleted 4y ago
[deleted]

yxhuvud 4y ago

It is easy until you have to support the look and feel of two different server side environments.

marcodiego 4y ago

I remember an old post years ago on DOSBox forum. Someone posted a patch to update the number of FPS on the window titlebar. Someone else tried it came back complaining that it ate the processor. A bit of investigation revealed how expensive it was to update the titlebar: DOSBox, in some form, notified the DE (window manager) that the titlebar needed update; then the window manager informed the window decorator about the update; it then updated the titlebar and notified X11 to redraw it; X11 then had to sync all that to post new screen with everything ready to show. Now, go back and count the number of processes and calculate how many context switches were required just to update the titlebar. Server-side decoration made things more modular because it allowed the window decorator to be an entirely independent process. It could allow to use Beryl or kwin or any other window decorator with compiz, for example. Even considering these advantages, the price one paid for it was too expensive to justify. X11 did it, basically nobody else did; certainly for a good reason. Server-side decoration is one thing I'm glad we are finally getting rid of.