5 ms·

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

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.
  - espadrine 10y ago
    Blame is not on toolkits. The history is clear: came a point where MacOS X and Windows supported flawless animations with no screen tearing, and transparency, and antialiased rounded corners for windows. Meanwhile, Linux still had blitted windows that left a grey trace for a brief instant when you moved them, and pixelwise window edges, and terrible transparency. Came along Compiz, which reversed the way clients interacted with X, and which did the slick animations and fancy graphics of the mainstream OSes. What was the only way it found to do that? Rendering everything outside of X. And nobody could do it with the old design. So that design was quickly adopted by KWin and so on. It turns out that nowadays screens are not lightweight clients over a serial line, and they have more than double the number of pixels of VGA. Compositors became a necessity for the Linux Desktop to compete, reducing X to an IPC system that it cannot be good at, because it is not the situation it was built for. Wayland is built for the status quo.

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.
- espadrine 10y ago
  Blame is not on toolkits. The history is clear: came a point where MacOS X and Windows supported flawless animations with no screen tearing, and transparency, and antialiased rounded corners for windows. Meanwhile, Linux still had blitted windows that left a grey trace for a brief instant when you moved them, and pixelwise window edges, and terrible transparency. Came along Compiz, which reversed the way clients interacted with X, and which did the slick animations and fancy graphics of the mainstream OSes. What was the only way it found to do that? Rendering everything outside of X. And nobody could do it with the old design. So that design was quickly adopted by KWin and so on. It turns out that nowadays screens are not lightweight clients over a serial line, and they have more than double the number of pixels of VGA. Compositors became a necessity for the Linux Desktop to compete, reducing X to an IPC system that it cannot be good at, because it is not the situation it was built for. Wayland is built for the status quo.