5 ms·

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.
    - nitrogen 10y ago
      I haven't done much 2D drawing recently. My intuition is that sending a batch of line/polygon/stipple/fill commands to a GPU would be more efficient than occupying a CPU and then using a bunch of memory bandwidth to transfer a bitmap. But on modern systems, software rendering to a bitmap in RAM is more efficient than sending a command to a GPU (which probably lacks dedicated 2D hardware)?
      - lomnakkus 10y ago
        RAM/DMA transfer is absurdly fast these days. (And "as a compositor" you'll have to do it anyway at 60fps, regardless.)
      - TD-Linux 10y ago
        GPU drawing can still be faster than on the CPU, and you can do that with Wayland, by directly opening the DRM device (/dev/dri/render*) and sending the rendering commands directly to the GPU. This is how Mesa implements OpenGL on both X and Wayland. The X way requires you to send XRender commands to the X server first, and then it sends them to the GPU. This was already too slow (hence the already existing bypass for OpenGL) and Wayland just extends that idea to all rendering.
      - digi_owl 10y ago
        Bingo. X was in part made for working over network and serial connections. And for that it works quite well when the clients play nice (async code between front and back end etc). But the major toolkits have taken to rendering everything outside of X and just dumping the result as a bitmap into a box, that is absurd for all but the most local of work. And yet they complain about X being the problem. X is not the problem. The problem is a generation of devs coming over from MS and Apple platforms and not recognizing that X is different. They just want to dump their eyecandy into the buffer and rely on Moore's Law for things drawing more than 1 pixel an hour.
        bitwize 10y ago
        "Rendering everything outside of X" means directly accessing the GPU. Doing GPU stuff through X is slow and for DRI, the X server gets in the way. And X's 2D rendering primitives are obsolete. You want 2D primitives? It's called libcairo. Wayland provides the missing piece, the only bit of X anyone actually uses: providing buffers to clients to render into to be composited on the display. Just about everyone who has worked seriously on Linux graphics agrees that X is a problem and Wayland is the solution. You might want to look into why they all say the same thing.
- ibotty 10y ago
  > Seriously, when's the last time you wrote a program that relied on the ability of the display server to draw stippled lines? or someone?
  - stinkytaco 10y ago
    Then they can implement stippled lines in their application. It seems absurd to expect X to support rarely used extensions simply because "someone" might use them. It's not like stippled lines are no longer allowed on the Linux desktop, you just can't hook into the desktop compositor to get them.
lomnakkus 10y ago
The X.org developers decided. The person who started Wayland was an X.org developer, and IIUC many who joined the effort are/were X.org developers, etc. > I am sure that if you poke around you will find someone still relying on those features being present daily. Not really. Many of these things have been broken in X.org for years and years... because nobody used them! (Again, see the talk.) There's also the whole abysmal security record of X11[1], due in large part to the huge API and the fact that all serialization/deserialization of requests is hand-coded (by necessity). [1] https://www.youtube.com/watch?v=2l7ixRE3OCw https://www.youtube.com/watch?v=2l7ixRE3OCw

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.
  - nitrogen 10y ago
    I haven't done much 2D drawing recently. My intuition is that sending a batch of line/polygon/stipple/fill commands to a GPU would be more efficient than occupying a CPU and then using a bunch of memory bandwidth to transfer a bitmap. But on modern systems, software rendering to a bitmap in RAM is more efficient than sending a command to a GPU (which probably lacks dedicated 2D hardware)?
    - lomnakkus 10y ago
      RAM/DMA transfer is absurdly fast these days. (And "as a compositor" you'll have to do it anyway at 60fps, regardless.)
    - TD-Linux 10y ago
      GPU drawing can still be faster than on the CPU, and you can do that with Wayland, by directly opening the DRM device (/dev/dri/render*) and sending the rendering commands directly to the GPU. This is how Mesa implements OpenGL on both X and Wayland. The X way requires you to send XRender commands to the X server first, and then it sends them to the GPU. This was already too slow (hence the already existing bypass for OpenGL) and Wayland just extends that idea to all rendering.
    - digi_owl 10y ago
      Bingo. X was in part made for working over network and serial connections. And for that it works quite well when the clients play nice (async code between front and back end etc). But the major toolkits have taken to rendering everything outside of X and just dumping the result as a bitmap into a box, that is absurd for all but the most local of work. And yet they complain about X being the problem. X is not the problem. The problem is a generation of devs coming over from MS and Apple platforms and not recognizing that X is different. They just want to dump their eyecandy into the buffer and rely on Moore's Law for things drawing more than 1 pixel an hour.
      - bitwize 10y ago
        "Rendering everything outside of X" means directly accessing the GPU. Doing GPU stuff through X is slow and for DRI, the X server gets in the way. And X's 2D rendering primitives are obsolete. You want 2D primitives? It's called libcairo. Wayland provides the missing piece, the only bit of X anyone actually uses: providing buffers to clients to render into to be composited on the display. Just about everyone who has worked seriously on Linux graphics agrees that X is a problem and Wayland is the solution. You might want to look into why they all say the same thing.
ibotty 10y ago
> Seriously, when's the last time you wrote a program that relied on the ability of the display server to draw stippled lines? or someone?
- stinkytaco 10y ago
  Then they can implement stippled lines in their application. It seems absurd to expect X to support rarely used extensions simply because "someone" might use them. It's not like stippled lines are no longer allowed on the Linux desktop, you just can't hook into the desktop compositor to get them.

lomnakkus 10y ago

The X.org developers decided. The person who started Wayland was an X.org developer, and IIUC many who joined the effort are/were X.org developers, etc. > I am sure that if you poke around you will find someone still relying on those features being present daily. Not really. Many of these things have been broken in X.org for years and years... because nobody used them! (Again, see the talk.) There's also the whole abysmal security record of X11[1], due in large part to the huge API and the fact that all serialization/deserialization of requests is hand-coded (by necessity). [1] https://www.youtube.com/watch?v=2l7ixRE3OCw https://www.youtube.com/watch?v=2l7ixRE3OCw