8 ms·

> With a compositor on top of X I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless. But even if

> With a compositor on top of X I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless. But even if you do, the compositor only does one job: layer graphics. Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc. Wayland either fragments this (saying it is all the compositor's problem or punts it to dbus or something), or ignores it (they feel about useful things the way I feel about compositors), and will likely reinvent it eventually anyway. And btw, what about X is unnecessarily complicated? I love the way the presenter claims the specs are impossible but I managed to implement them and so did a bunch of other people. So apparently it isn't actually that hard. and btw they aren't actually all that different than similar functionality in different operating systems, aside from things like asynchronous chunking... which is a good thing, since you don't want to block your UI event loop anyway! So it is what good programs ought to be already doing.

kaba0 5y ago
> I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless. Have you tried watching a video in full screen? > But even if you do, the compositor only does one job: layer graphics Yes, and this small little detail is not solved by X, but Wayland. > Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc. And it will live on in the form of XWayland. And I do dislike needlessly dropping backward compatibility, X’s APIs are globally broadcasted, and can’t really be retrofitted to an only server-client communication, so it makes sense to “reinvent” it. > I love the way the presenter claims the specs are impossible but I managed to implement them What part of it? I doubt you included the now removed printer part and the million other things the X developers had to cut out with hard work. And as I said, XWayland is made explicitly for this high level API of X, it is not going anywhere. And I’m not sure what you mean by asynchronous chunking. You mean tearing? You do have to synchronize somewhere.
- destructionator 5y ago
  > Have you tried watching a video in full screen? Nah, I've actually never used a computer since 1995. What is this "yoo-tubes" thing all the kids are talking about nowadays anyway? You do realize that X applications can use DRI too right? And vsync when they swap buffers? This is trivially easy. The only time I've ever seen glitches is if I tweak a couple config options with the intention of causing it, run a poorly-behaving program, and then resize it rapidly up and down. That'll cause a flicker. > X’s APIs are globally broadcasted No, they're not. I imagine you must think thinking of one client deliberately selecting the input of another client's window, which is allowed (unless the client is untrusted, e.g. an application from a `ssh -X` session - yes, X does support "untrusted" connections and restricts their access, and has since like 2007), but that's still not broadcast per se; you only receive a copy of the message if you specifically requested it. > What part of it? Drag and drop, clipboard, docking, window manager hints; here I was referring to the extension specs used for IPC with the X server. And it is really pretty cool what you can do with this. If you run two applications on separate computers, you can drag and drop stuff between them and it just works. That's the asynchronous chunking I referred to, again this was in the context of "unnecessarily complicated IPC". There's a size limit and acknowledgement protocol in transferring things like drops and pastes and your program is never supposed to block on those cases, rather go back to the full event loop. This is a bit more complicated to program, but it has several benefits, even on non-network cases (like say pasting a gigabyte on a Windows box) - you can stay responsive to the user while working in the background, show progress bars and cancel buttons, etc. (Now if you're on the same machine btw the spec says to optimize some of these things and, for example, transfer a filename instead of file contents and let them read it themselves. The youtube video is half-correct when he says X isn't network transparent. Actually, a surprising amount of things are, like you can often run (old-style) OpenGL programs on remote hosts even if the author didn't plan on that! But if you want best results, you do need to have local machine optimization branches. If local machine, use shared memory instead of buffer transfers. If local machine, send file name instead of contents on drop event. Stuff like that. I also personally do things like if remote machine, disable mouse motion events unless a button is held down, just so save on bandwidth, though of course that's not a big deal anymore, but the core protocol does make that trivially easy to do!) wrt tearing - which again I virtually never see on X (I have to go out of my way to trigger it!) so I really don't know why people complain about that so much - again you can vsync easily with glx and double buffer easily in any program. There's even a XSync extension you can use to help with these, even across clients: https://www.x.org/releases/X11R7.6/doc/libXext/synclib.html https://www.x.org/releases/X11R7.6/doc/libXext/synclib.html (note the date on that: 1991. It isn't like this stuff is new.)

kaba0 5y ago

> I reject that premise. I've never used a compositor and I don't know why anyone would, they seem utterly useless. Have you tried watching a video in full screen? > But even if you do, the compositor only does one job: layer graphics Yes, and this small little detail is not solved by X, but Wayland. > Most X messages have nothing to do with graphics. They're more likely to be about clipboard, drag and drop, notification windows, taskbar panels, etc., etc., etc. And it will live on in the form of XWayland. And I do dislike needlessly dropping backward compatibility, X’s APIs are globally broadcasted, and can’t really be retrofitted to an only server-client communication, so it makes sense to “reinvent” it. > I love the way the presenter claims the specs are impossible but I managed to implement them What part of it? I doubt you included the now removed printer part and the million other things the X developers had to cut out with hard work. And as I said, XWayland is made explicitly for this high level API of X, it is not going anywhere. And I’m not sure what you mean by asynchronous chunking. You mean tearing? You do have to synchronize somewhere.

destructionator 5y ago
> Have you tried watching a video in full screen? Nah, I've actually never used a computer since 1995. What is this "yoo-tubes" thing all the kids are talking about nowadays anyway? You do realize that X applications can use DRI too right? And vsync when they swap buffers? This is trivially easy. The only time I've ever seen glitches is if I tweak a couple config options with the intention of causing it, run a poorly-behaving program, and then resize it rapidly up and down. That'll cause a flicker. > X’s APIs are globally broadcasted No, they're not. I imagine you must think thinking of one client deliberately selecting the input of another client's window, which is allowed (unless the client is untrusted, e.g. an application from a `ssh -X` session - yes, X does support "untrusted" connections and restricts their access, and has since like 2007), but that's still not broadcast per se; you only receive a copy of the message if you specifically requested it. > What part of it? Drag and drop, clipboard, docking, window manager hints; here I was referring to the extension specs used for IPC with the X server. And it is really pretty cool what you can do with this. If you run two applications on separate computers, you can drag and drop stuff between them and it just works. That's the asynchronous chunking I referred to, again this was in the context of "unnecessarily complicated IPC". There's a size limit and acknowledgement protocol in transferring things like drops and pastes and your program is never supposed to block on those cases, rather go back to the full event loop. This is a bit more complicated to program, but it has several benefits, even on non-network cases (like say pasting a gigabyte on a Windows box) - you can stay responsive to the user while working in the background, show progress bars and cancel buttons, etc. (Now if you're on the same machine btw the spec says to optimize some of these things and, for example, transfer a filename instead of file contents and let them read it themselves. The youtube video is half-correct when he says X isn't network transparent. Actually, a surprising amount of things are, like you can often run (old-style) OpenGL programs on remote hosts even if the author didn't plan on that! But if you want best results, you do need to have local machine optimization branches. If local machine, use shared memory instead of buffer transfers. If local machine, send file name instead of contents on drop event. Stuff like that. I also personally do things like if remote machine, disable mouse motion events unless a button is held down, just so save on bandwidth, though of course that's not a big deal anymore, but the core protocol does make that trivially easy to do!) wrt tearing - which again I virtually never see on X (I have to go out of my way to trigger it!) so I really don't know why people complain about that so much - again you can vsync easily with glx and double buffer easily in any program. There's even a XSync extension you can use to help with these, even across clients: https://www.x.org/releases/X11R7.6/doc/libXext/synclib.html https://www.x.org/releases/X11R7.6/doc/libXext/synclib.html (note the date on that: 1991. It isn't like this stuff is new.)