The coolest thing this article taught me, and I have to give it a more full read next time, is how the Expose event works. It explains why you get those duplication of windows when you drag it over an application which is running slowly, therefore responding to regional update requests very slowly that you actual see an unupdated frontbuffer (is that the right word?) for some time.
The one thing missing for me (skimming some of the later bits, I might have missed it) in this was discussion of the DAMAGE extension. This confused me when I read the docs (15 years ago, they might be better now) because there’s a conceptual jump: Damage is the opposite of expose, but in my mental model it was the same and I couldn’t see how it worked. Composite, render, and damage are typically all used together as a group and the article did discuss the first two.
So if I have Firefox fullscreen and I move a terminal over it. My example then was expose in the case of X requesting firerfox to provide the region update for where the terminal window was.
Then damage is more like firefox asking, hey what’s infront of me?
No damage is firefox saying ‘someone typed in this text field, so this bit needs redrawing, I have updated the Picture, you need to redo the compositing’.
Oh that makes sense and now I can see why the terminology sounds confusing and would make sense being the other way around. It would make sense for window above me damaged me, redraw region, hey I have a region I want to update, expose this to x
With a compositing display server, you don’t need expose notifications because the application draws an entire window and it’s up to the compositing manager to display the exposed parts (often by sending all of them as textures to the GPU and just drawing them on rectangles on top of each other). You do, however, need to tell the compositing manager when you have updated part of your own window, because otherwise it doesn’t know that it needs to redraw. You can do this by tracking updates to the layers in the window transparently, but sometimes it’s a lot more efficient to be told ‘the only part of this window that’s changed is this little tiny bit’. For example, consider a flashing cursor in a text box: only a handful of pixels change, so you can avoid a lot of network bandwidth for remote displays or a chunk of PCIe bus bandwidth locally by sending only a small update to a texture rather than the whole thing. That’s what the damage extension is for.
Yeah, another good example is screen sharing/recording applications, being told what to find instead of screenshotting the whole display X times a second and trying to find differences.
So I like this pagetoo, but there’s some things I wish had asterisks. For example:
There’s no way to mark an X11 window as a menu or a button.
For example is technically true, the X11 protocol doesn’t include this semantic info. But things built on top of it do: a EWMH property can do this…. well sort of anyway, the _NET_WM_WINDOW_TYPE property can be set for the semantics of various top-level windows. There’s a decent parallel between X window properties and html attributes, with how they enable various extensions.
That said, I agree with the overall point that actually making your widgets out of X windows is a mistaken design.
But then every article promises to get into “Expert window techniques” and it never does, instead getting sidetracked into transparency. At least the COMPOSITE extension is still part of X, but it just goes off the rails from there. The region stuff is a tangent, barely touching anymore at that point, then 2d rasterization is interesting general knowledge, but completely disconnected from the X Window System. And it is a pity, because a lot of the X knowledge beyond there is somewhat obscure (perhaps very obscure, since there’s some big projects that do things like XEMBED wrong!) and the approach from the beginning might have illuminated that really nicely.
The fact that you can combine windows from multiple sources is legitimately cool. And the non-graphics part of X - which are important parts of a gui user experience - are interesting too, and how they work through the server to unify behavior between applications running on various systems is also legitimately cool and again, I think not well understood.
If you just look at questions of transparency, you miss out on a whole world of joy.
Well worth reading. This is probably the clearest and most approachable introduction to X11 that I’ve read.
The coolest thing this article taught me, and I have to give it a more full read next time, is how the
Exposeevent works. It explains why you get those duplication of windows when you drag it over an application which is running slowly, therefore responding to regional update requests very slowly that you actual see an unupdated frontbuffer (is that the right word?) for some time.That for me was groundbreaking knowledge :)
The one thing missing for me (skimming some of the later bits, I might have missed it) in this was discussion of the DAMAGE extension. This confused me when I read the docs (15 years ago, they might be better now) because there’s a conceptual jump: Damage is the opposite of expose, but in my mental model it was the same and I couldn’t see how it worked. Composite, render, and damage are typically all used together as a group and the article did discuss the first two.
So if I have Firefox fullscreen and I move a terminal over it. My example then was expose in the case of X requesting firerfox to provide the region update for where the terminal window was.
Then damage is more like firefox asking, hey what’s infront of me?
No damage is firefox saying ‘someone typed in this text field, so this bit needs redrawing, I have updated the Picture, you need to redo the compositing’.
Oh that makes sense and now I can see why the terminology sounds confusing and would make sense being the other way around. It would make sense for window above me damaged me, redraw region, hey I have a region I want to update, expose this to x
Thanks for the clarification!
With a compositing display server, you don’t need expose notifications because the application draws an entire window and it’s up to the compositing manager to display the exposed parts (often by sending all of them as textures to the GPU and just drawing them on rectangles on top of each other). You do, however, need to tell the compositing manager when you have updated part of your own window, because otherwise it doesn’t know that it needs to redraw. You can do this by tracking updates to the layers in the window transparently, but sometimes it’s a lot more efficient to be told ‘the only part of this window that’s changed is this little tiny bit’. For example, consider a flashing cursor in a text box: only a handful of pixels change, so you can avoid a lot of network bandwidth for remote displays or a chunk of PCIe bus bandwidth locally by sending only a small update to a texture rather than the whole thing. That’s what the damage extension is for.
Thank you for explaining David :)
Yeah, another good example is screen sharing/recording applications, being told what to find instead of screenshotting the whole display X times a second and trying to find differences.
So I like this pagetoo, but there’s some things I wish had asterisks. For example:
For example is technically true, the X11 protocol doesn’t include this semantic info. But things built on top of it do: a EWMH property can do this…. well sort of anyway, the _NET_WM_WINDOW_TYPE property can be set for the semantics of various top-level windows. There’s a decent parallel between X window properties and html attributes, with how they enable various extensions.
That said, I agree with the overall point that actually making your widgets out of X windows is a mistaken design.
But then every article promises to get into “Expert window techniques” and it never does, instead getting sidetracked into transparency. At least the COMPOSITE extension is still part of X, but it just goes off the rails from there. The region stuff is a tangent, barely touching anymore at that point, then 2d rasterization is interesting general knowledge, but completely disconnected from the X Window System. And it is a pity, because a lot of the X knowledge beyond there is somewhat obscure (perhaps very obscure, since there’s some big projects that do things like XEMBED wrong!) and the approach from the beginning might have illuminated that really nicely.
The fact that you can combine windows from multiple sources is legitimately cool. And the non-graphics part of X - which are important parts of a gui user experience - are interesting too, and how they work through the server to unify behavior between applications running on various systems is also legitimately cool and again, I think not well understood.
If you just look at questions of transparency, you miss out on a whole world of joy.