6 ms·

> If I understand correctly from following the Gnome and KWin blogs, in Wayland it looks like the "window management" job is with the Compositor, which takes on

> If I understand correctly from following the Gnome and KWin blogs, in Wayland it looks like the "window management" job is with the Compositor, which takes on a lot more of the display and input work that was traditionally handled by the X Server. This is basically right. However, you have to remember that the Wayland protocol is at least an order of magnitude (if not two) smaller than X11. It's also defined/specced using a machine-readable XML document which means that an implementation of the protocol can basically be auto-generated from the spec document -- thus making it a lot easier to keep your implementation up to date. > This would mean that we're unlikely to see the proliferation of WM experiments that X saw. Remains to be seen, I guess.

digi_owl 10y ago
Give W as much time as X11 has had, and it will be of comparable size as X11 is right now. They will perhaps try to play semantic games by putting much of the additions into support libs that you "don't need", unless you want to run anything more than a decade old. Wayland, X11, SVGALib, F if i can tell a diff...
- lomnakkus 10y ago
  No. It's already basically feature-complete as compared to which parts of X11 are actually used these days[1]. X11 is burdened by absurdly obsolete extensions like drawing stippled lines, a font server, etc. See the talk by Daniel Stone[2] if you're interested in the kind of crud that's been cleared out. It's basically the kind of stuff that we will never go back to wanting in any type of server process. The trade-off between bandwidth and latency has changed fundamentally in basically all areas of computing, but especially anything to do with graphics. [1] Alright, there might be a few bits and bobs that are missing, but nothing major as witnessed by the very article under discussion. [2] https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44
  - digi_owl 10y ago
    Who gets to declare those things "crud"? I am sure that if you poke around you will find someone still relying on those features being present daily.
    - bonzini 10y ago
      xterm and rxvt do.
    - mgbmtl 10y ago
      You can usually tell by the very few people willing to maintain the code/feature. Some of it has layers upon layers of duct tape.
    - bitwize 10y ago
      Daniel Stone does. Maybe you get a say in it when you've spent as much time on the Linux graphics stack as Daniel Stone has. Seriously, when's the last time you wrote a program that relied on the ability of the display server to draw stippled lines?
      - nitrogen 10y ago
        What's so bad about stippled lines? They sound useful for so-called "real work" applications for drawing grids and graphs and marching ants.
        lomnakkus 10y ago
        It's not that stippled line are bad per se. It's just that they shouldn't be baked into a protocol that goes "over the wire" (so to speak). It's much faster if the program just gets a bitmap to draw on and draw the stippled line itself. It's important to note here that "itself" could mean that you just call a (Qt/Gtk/SDL/whatever) library function to do it. There's no conceivable reason (these days) that you'd want to send a "draw a stippled line from point a to point b" command to an X server or graphics card.
        10y ago

digi_owl 10y ago

Give W as much time as X11 has had, and it will be of comparable size as X11 is right now. They will perhaps try to play semantic games by putting much of the additions into support libs that you "don't need", unless you want to run anything more than a decade old. Wayland, X11, SVGALib, F if i can tell a diff...

lomnakkus 10y ago
No. It's already basically feature-complete as compared to which parts of X11 are actually used these days[1]. X11 is burdened by absurdly obsolete extensions like drawing stippled lines, a font server, etc. See the talk by Daniel Stone[2] if you're interested in the kind of crud that's been cleared out. It's basically the kind of stuff that we will never go back to wanting in any type of server process. The trade-off between bandwidth and latency has changed fundamentally in basically all areas of computing, but especially anything to do with graphics. [1] Alright, there might be a few bits and bobs that are missing, but nothing major as witnessed by the very article under discussion. [2] https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44
- digi_owl 10y ago
  Who gets to declare those things "crud"? I am sure that if you poke around you will find someone still relying on those features being present daily.
  - bonzini 10y ago
    xterm and rxvt do.
  - mgbmtl 10y ago
    You can usually tell by the very few people willing to maintain the code/feature. Some of it has layers upon layers of duct tape.
  - bitwize 10y ago
    Daniel Stone does. Maybe you get a say in it when you've spent as much time on the Linux graphics stack as Daniel Stone has. Seriously, when's the last time you wrote a program that relied on the ability of the display server to draw stippled lines?
    - nitrogen 10y ago
      What's so bad about stippled lines? They sound useful for so-called "real work" applications for drawing grids and graphs and marching ants.
      - lomnakkus 10y ago
        It's not that stippled line are bad per se. It's just that they shouldn't be baked into a protocol that goes "over the wire" (so to speak). It's much faster if the program just gets a bitmap to draw on and draw the stippled line itself. It's important to note here that "itself" could mean that you just call a (Qt/Gtk/SDL/whatever) library function to do it. There's no conceivable reason (these days) that you'd want to send a "draw a stippled line from point a to point b" command to an X server or graphics card.
        10y ago