6 ms·

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

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

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.