6 ms·

> Shit hit the X11 fan as the DEs adopted OpenGL as an UI accelerator, effectively bypassing X for most tasks. That's not correct. If DEs actually were using O

> Shit hit the X11 fan as the DEs adopted OpenGL as an UI accelerator, effectively bypassing X for most tasks. That's not correct. If DEs actually were using OpenGL for UI acceleration, then at least for GL-2.1 and earlier everything would be sent as pure drawing commands to the display server by means of the X11/GLX transport protocol (indirect rendering context). What actually happened was, that for some reason the developers of the toolkits thought, that it was somehow necessary to render everything in the client into a pixmap and only as a last step pass this through the X11 to the graphics hardware, thereby degrading the X11 server to a glorified bit-blitting machine. That's why the design of Wayland is how it is, because toolkits developers couldn't be bothered to actually using the X11 drawing primitives in a clever way. And if you're not a total moron you can make it look extremely good. One thing that I never understood is, why antialiasing was never enabled for X core drawing primitives; it's not like you couldn't use raster ops with antialiased geometry either (like the XOR overdraw method).

digi_owl 10y ago
That was basically what i was talking about in the second part. They started out with GLX, but then switched to KMS and going directly to the hardware. Best i can tell, this was done because GLX was seen as holding them back somehow. Then again i have found the whole compositor thing unreliable at best. I still have it turned off on my (aging) XFCE install. Anyways, i think the primary reason they want X11 dead is the whole security thing. It seems there is not a week going by without some blog or other warning about how anything can sniff and/or insert keystrokes in X11, never mind screen scraping, and how Wayland will fix all that. Never mind that one man's security issue is another man's feature...
- deleted 10y ago
  [deleted]
- datenwolf 10y ago
  > but then switched to KMS and going directly to the hardware That's not how it works. KMS is something display servers (X11, Wayland compositor) use, not something a client application should or would use (too impractical.
  - digi_owl 10y ago
    Yeah i guess i got that mixed up with DRI, though i can't say i payed much attention to either until all the hoopla about Wayland started.
    - datenwolf 10y ago
      > Yeah i guess i got that mixed up with DRI, though. DRI only comes into play if you're creating a direct OpenGL context running one of the open source OpenGL drivers (Mesa + DRM). It does nothing for regular X11 clients, that don't use OpenGL. Actually DRI does not do drawing at all, it's mostly just a way for bypassing the X11 server for direct OpenGL contexts as specified in the GLX specification. Essentially it's shared memory plus mmaping certain regions of the video device into clients' address spaces. You can't draw shit using DRI. Again: This neither KMS, nor DRI/DRM, nor OpenGL have anything to do with the braindeadness of "modern" X11 toolkits. What does have something to do with it is reinventing the wheel and to all the rasterization work in software client side in code contained in the toolkit (Cairo in the case of GTK+, "raster" in the case of Qt). Why these custom rasterization engines have been implemented? Well, mostly to be able to use the toolkits in an embedded environment that lacks a display server with drawing primitives (for example DirectFB). Eventually the scope expanded to draw single widgets for X11 and at some point it was decided that it would be easier to just render the whole thing in software and then blit. People were dissatisfied with the graphics primitives offered by X11 / XRender. Yes, I admit, rectangles, triangles, polygons, lines, arcs and ellipses are not that much (/s); there's still the desire for Bezier curves. And yes, I admit that the X11 graphics model may be somewhat limiting when it comes to composing drawing layers, as you need it for, say CSS. However I consider it mostly a lack of creativity and determination. XRender can be quite powerful if you know how to use it. And with Glamor at last it will be GPU accelerated.
      - digi_owl 10y ago
        And thats the thing. At least from my point of view, Cairo and the like was "happy" exiting within X11. But once we got things like Compiz, a major shift in attitude towards X11 came about.
DonHopkins 10y ago
There's no way X can do anti-aliasing, without a ground-up redesign. The rendering rules are very strictly defined in terms of which pixels get touched and how. There is a deep-down irreconcilable philosophical and mathematical difference between X11's discrete half-open pixel-oriented rendering model, and PostScript's continuous stencil/paint Porter/Duff imaging model. X11 graphics round differently when filling and stroking, define strokes in terms of square pixels instead of fills with arbitrary coordinate transformations, and is all about "half open" pixels with gravity to the right and down, not the pixel coverage of geometric region, which is how anti-aliasing is defined. X11 is rasterops on wheels. It turned out that not many application developers enjoyed thinking about pixels and coordinates the X11 way, displays don't always have square pixels, the hardware (cough Microvax framebuffer) that supports rasterops efficiently is long obsolete, rendering was precisely defined in a way that didn't allow any wiggle room for hardware optimizations, and developers would rather use higher level stencil/paint and scalable graphics, now that computers are fast enough to support it. I tried describing the problem in the Unix-Haters X-Windows Disaster chapter [1]: A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that "in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion)." This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio. [1] The X-Windows Disaster: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...
- 10y ago

digi_owl 10y ago

That was basically what i was talking about in the second part. They started out with GLX, but then switched to KMS and going directly to the hardware. Best i can tell, this was done because GLX was seen as holding them back somehow. Then again i have found the whole compositor thing unreliable at best. I still have it turned off on my (aging) XFCE install. Anyways, i think the primary reason they want X11 dead is the whole security thing. It seems there is not a week going by without some blog or other warning about how anything can sniff and/or insert keystrokes in X11, never mind screen scraping, and how Wayland will fix all that. Never mind that one man's security issue is another man's feature...

deleted 10y ago
[deleted]
datenwolf 10y ago
> but then switched to KMS and going directly to the hardware That's not how it works. KMS is something display servers (X11, Wayland compositor) use, not something a client application should or would use (too impractical.
- digi_owl 10y ago
  Yeah i guess i got that mixed up with DRI, though i can't say i payed much attention to either until all the hoopla about Wayland started.
  - datenwolf 10y ago
    > Yeah i guess i got that mixed up with DRI, though. DRI only comes into play if you're creating a direct OpenGL context running one of the open source OpenGL drivers (Mesa + DRM). It does nothing for regular X11 clients, that don't use OpenGL. Actually DRI does not do drawing at all, it's mostly just a way for bypassing the X11 server for direct OpenGL contexts as specified in the GLX specification. Essentially it's shared memory plus mmaping certain regions of the video device into clients' address spaces. You can't draw shit using DRI. Again: This neither KMS, nor DRI/DRM, nor OpenGL have anything to do with the braindeadness of "modern" X11 toolkits. What does have something to do with it is reinventing the wheel and to all the rasterization work in software client side in code contained in the toolkit (Cairo in the case of GTK+, "raster" in the case of Qt). Why these custom rasterization engines have been implemented? Well, mostly to be able to use the toolkits in an embedded environment that lacks a display server with drawing primitives (for example DirectFB). Eventually the scope expanded to draw single widgets for X11 and at some point it was decided that it would be easier to just render the whole thing in software and then blit. People were dissatisfied with the graphics primitives offered by X11 / XRender. Yes, I admit, rectangles, triangles, polygons, lines, arcs and ellipses are not that much (/s); there's still the desire for Bezier curves. And yes, I admit that the X11 graphics model may be somewhat limiting when it comes to composing drawing layers, as you need it for, say CSS. However I consider it mostly a lack of creativity and determination. XRender can be quite powerful if you know how to use it. And with Glamor at last it will be GPU accelerated.
    - digi_owl 10y ago
      And thats the thing. At least from my point of view, Cairo and the like was "happy" exiting within X11. But once we got things like Compiz, a major shift in attitude towards X11 came about.

DonHopkins 10y ago

There's no way X can do anti-aliasing, without a ground-up redesign. The rendering rules are very strictly defined in terms of which pixels get touched and how. There is a deep-down irreconcilable philosophical and mathematical difference between X11's discrete half-open pixel-oriented rendering model, and PostScript's continuous stencil/paint Porter/Duff imaging model. X11 graphics round differently when filling and stroking, define strokes in terms of square pixels instead of fills with arbitrary coordinate transformations, and is all about "half open" pixels with gravity to the right and down, not the pixel coverage of geometric region, which is how anti-aliasing is defined. X11 is rasterops on wheels. It turned out that not many application developers enjoyed thinking about pixels and coordinates the X11 way, displays don't always have square pixels, the hardware (cough Microvax framebuffer) that supports rasterops efficiently is long obsolete, rendering was precisely defined in a way that didn't allow any wiggle room for hardware optimizations, and developers would rather use higher level stencil/paint and scalable graphics, now that computers are fast enough to support it. I tried describing the problem in the Unix-Haters X-Windows Disaster chapter [1]: A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules. When you fill a 10x10 square with XFillRectangle, it fills the 100 pixels you expect. But you get extra "bonus pixels" when you pass the same arguments to XDrawRectangle, because it actually draws an 11x11 square, hanging out one pixel below and to the right!!! If you find this hard to believe, look it up in the X manual yourself: Volume 1, Section 6.1.4. The manual patronizingly explains how easy it is to add 1 to the x and y position of the filled rectangle, while subtracting 1 from the width and height to compensate, so it fits neatly inside the outline. Then it points out that "in the case of arcs, however, this is a much more difficult proposition (probably impossible in a portable fashion)." This means that portably filling and stroking an arbitrarily scaled arc without overlapping or leaving gaps is an intractable problem when using the X Window System. Think about that. You can't even draw a proper rectangle with a thick outline, since the line width is specified in unscaled pixel units, so if your display has rectangular pixels, the vertical and horizontal lines will have different thicknesses even though you scaled the rectangle corner coordinates to compensate for the aspect ratio. [1] The X-Windows Disaster: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html http://www.art.net/~hopkins/Don/unix-haters/x-windows/disast...

10y ago