3 ms·

This is one of the benefits of the Wayland protocol over X, being able to do this kind of thing relatively straightforwardly. Once support for hardware planes

This is one of the benefits of the Wayland protocol over X, being able to do this kind of thing relatively straightforwardly. Once support for hardware planes becomes more common in Wayland compositors, this can be tied to ultimately allow no-copy rendering to the display for non-fullscreen applications, which for video playback (incl. likes of Youtube) equals to reduced CPU & GPU usage and less power draw, as well as reduced latency.

AshamedCaptain 3y ago
> This is one of the benefits of the Wayland protocol over X What. The original design of X actually encouraged a separate surface / Window for each single widget on your UI. This was actually removed in Gtk+3 ("windowless widgets"). And now they are bringing it back just for wayland ("subsurfaces"). As far as I can read, it is practically the same concept.
- tadfisher 3y ago
  The original design of X had clients send drawing commands to the X server, basically treating the server as a remote Cairo/Skia-like 2D rasterizer, and subwindows were a cheap way to avoid pixel-level damage calculations. This was obviated in the common case by the Xdamage extension. Later use of windows as a rendering surface for shared client/server buffers was added with Xshm, then for device video buffers with Xv. GTK3 got rid of windowed widgets because Keith Packard introduced the Xrender extension, which basically added 2D compositing to X, which was the last remaining use for subwindows for every widget.
  - AshamedCaptain 3y ago
    This is completely wrong. Xrender is completely orthogonal to having windows or not. Heck, Xrender takes a _window_ as target -- Xrender is just an extension to allow more complicated drawing commands to be sent to the server (like alpha composition). You make your toolkit's programmer's life more complicated, not less, by having windowless widgets (at the very minimum you now have to complicate your rendering & event handling code with offsets and clip regions and the like). The excuse that was used when introducing windowless widgets is to reduce tearing/noise during resizing, as Gtk+ had trouble synchronizing the resizing of all the windows at the same time.
    - play_ac 3y ago
      >Xrender is completely orthogonal to having windows or not. Heck, Xrender takes a _window_ as target -- Xrender is just an extension to allow more complicated drawing commands to be sent to the server (like alpha composition). Yes, that's the point. When you can tell Xrender to efficiently composite some pixmaps then there's really no reason to use sub-windows ever. >You make your toolkit's programmer's life more complicated, not less, by having windowless widgets (at the very minimum you now have to complicate your code with offsets and clip regions and the like). No, you still had to have offsets and clip regions before too because the client still had to set and update those. And it was more complicated because when you made a sub-window every single bit of state like that had to be synchronized with the X server and repeatedly copied over the wire. With client-side rendering everything is simply stored in the client and never has to deal with that problem.
      - AshamedCaptain 3y ago
        > When you can tell Xrender to efficiently composite some pixmaps then there's really no reason to use sub-windows ever. There is, or we would not be having subsurfaces on Wayland or this entire discussion in the first place. Are you seriously arguing that the only reason to using windows in Xorg is to have composition? People were using Xshape/Xmisc and the like to handle the lack of alpha channels in the core protocol? This is not what I remember. I would be surprised if Xshape even worked on non-top level windows. heck, even MOTIF had windowless widgets (called gadgets iirc), and the purpose most definitely was not composition-related.
        play_ac 3y ago
        >There is, or we would not be having subsurfaces on Wayland or this entire discussion in the first place. No. The subsurfaces in Wayland are only designed for two things: 1. Direct scan-out, as in TFA. (Because a subsurface can be directly translated to a dmabuf) 2. Embedding content from one toolkit/library into another. (Because without it, lots of glue code would be needed) It's discouraged to use them otherwise, they would complicate things for no benefit. >Are you seriously arguing that the only reason to using windows in Xorg is to have composition? If you mean sub-windows, yes, that and consequently because of the way that XRDB worked. I don't see why you would ever use them just for input events within the same toolkit, they don't do anything special there.
  - audidude 3y ago
    Drawables on Drawables doesn't help here at all. Sure it lets you do fast 2d acceleration but we don't use 2d accel infrastructure anywhere anymore. Subsurfaces have been in Wayland since the beginning of the protocol. This is simply getting them to work on demand so we can do something X (or Xv) could never do since Drawables would get moved to new memory (that may not even be mappable on the CPU-side) on every frame. And that's to actually use the scanout plane correctly to avoid powering up the 3d part of the GPU when doing video playback on composited systems.

AshamedCaptain 3y ago

> This is one of the benefits of the Wayland protocol over X What. The original design of X actually encouraged a separate surface / Window for each single widget on your UI. This was actually removed in Gtk+3 ("windowless widgets"). And now they are bringing it back just for wayland ("subsurfaces"). As far as I can read, it is practically the same concept.

tadfisher 3y ago
The original design of X had clients send drawing commands to the X server, basically treating the server as a remote Cairo/Skia-like 2D rasterizer, and subwindows were a cheap way to avoid pixel-level damage calculations. This was obviated in the common case by the Xdamage extension. Later use of windows as a rendering surface for shared client/server buffers was added with Xshm, then for device video buffers with Xv. GTK3 got rid of windowed widgets because Keith Packard introduced the Xrender extension, which basically added 2D compositing to X, which was the last remaining use for subwindows for every widget.
- AshamedCaptain 3y ago
  This is completely wrong. Xrender is completely orthogonal to having windows or not. Heck, Xrender takes a _window_ as target -- Xrender is just an extension to allow more complicated drawing commands to be sent to the server (like alpha composition). You make your toolkit's programmer's life more complicated, not less, by having windowless widgets (at the very minimum you now have to complicate your rendering & event handling code with offsets and clip regions and the like). The excuse that was used when introducing windowless widgets is to reduce tearing/noise during resizing, as Gtk+ had trouble synchronizing the resizing of all the windows at the same time.
  - play_ac 3y ago
    >Xrender is completely orthogonal to having windows or not. Heck, Xrender takes a _window_ as target -- Xrender is just an extension to allow more complicated drawing commands to be sent to the server (like alpha composition). Yes, that's the point. When you can tell Xrender to efficiently composite some pixmaps then there's really no reason to use sub-windows ever. >You make your toolkit's programmer's life more complicated, not less, by having windowless widgets (at the very minimum you now have to complicate your code with offsets and clip regions and the like). No, you still had to have offsets and clip regions before too because the client still had to set and update those. And it was more complicated because when you made a sub-window every single bit of state like that had to be synchronized with the X server and repeatedly copied over the wire. With client-side rendering everything is simply stored in the client and never has to deal with that problem.
    - AshamedCaptain 3y ago
      > When you can tell Xrender to efficiently composite some pixmaps then there's really no reason to use sub-windows ever. There is, or we would not be having subsurfaces on Wayland or this entire discussion in the first place. Are you seriously arguing that the only reason to using windows in Xorg is to have composition? People were using Xshape/Xmisc and the like to handle the lack of alpha channels in the core protocol? This is not what I remember. I would be surprised if Xshape even worked on non-top level windows. heck, even MOTIF had windowless widgets (called gadgets iirc), and the purpose most definitely was not composition-related.
      - play_ac 3y ago
        >There is, or we would not be having subsurfaces on Wayland or this entire discussion in the first place. No. The subsurfaces in Wayland are only designed for two things: 1. Direct scan-out, as in TFA. (Because a subsurface can be directly translated to a dmabuf) 2. Embedding content from one toolkit/library into another. (Because without it, lots of glue code would be needed) It's discouraged to use them otherwise, they would complicate things for no benefit. >Are you seriously arguing that the only reason to using windows in Xorg is to have composition? If you mean sub-windows, yes, that and consequently because of the way that XRDB worked. I don't see why you would ever use them just for input events within the same toolkit, they don't do anything special there.
- audidude 3y ago
  Drawables on Drawables doesn't help here at all. Sure it lets you do fast 2d acceleration but we don't use 2d accel infrastructure anywhere anymore. Subsurfaces have been in Wayland since the beginning of the protocol. This is simply getting them to work on demand so we can do something X (or Xv) could never do since Drawables would get moved to new memory (that may not even be mappable on the CPU-side) on every frame. And that's to actually use the scanout plane correctly to avoid powering up the 3d part of the GPU when doing video playback on composited systems.