CADT at work yet again it seems, as it the code could iterate faster if they were not bound by having the OGL traffic go through the X infrastructure.
From there is has been a hop skip to Wayland, where X is seen as a slowly withering appendage.
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).
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...
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.
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.
But once we got things like Compiz, a major shift in attitude towards X11 came about.
What the…? Are you trying to pull a "Hey, look over there, a three-headed monkey!"?! Why are you now pulling Compiz into the argument? It's totally irrelevant for this discussion.
Compiz is just a client that makes use of a concerted effort of the XRender, the Composite and the AIGLX extensions to composite whole windows to the screen. AIGLX is an acronym for "Accelerated Indirect GLX"; don't ask why that acroynm was chosen, because GLX itself already is accelerated and may be indirect.
Compositing also doesn't care about how you draw to a X11 drawable. All it cares about is: Here is a set of X11 drawables (windows, pixmaps), all server side, which you can draw to with server side accelerated rendering primitives. And then over there's a compositing surface (the composite layer window). The X11 server then is: "Now please give me drawing instructions on how to get the composite surface filled with the contents of the drawables!"
The compositing effects render completely server side, even if OpenGL graphics effects are used, thanks to indirect rendering command execution (heck, you can even compile the drawing commands in a display list (an ooold OpenGL feature; so old, it's been removed from modern OpenGL versions) and have the whole thing executed by sending a single glCallLists command to the X11 server via GLX).
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/disast...
If adding graphics primitives via X extensions worked as advertised, then X would have solved all these problems we're still having decades ago.
But as the HP technical support person said, "Why would you ever need to point to something that you've drawn in 3D?"
Indeed. But we're not talking about this. We're talking about the faux reasons why X11 toolkits started doing client-side rasterization (which is still pixel oriented), instead of doing just a little bit of work, making X-core primitives beautiful for framebuffers configured the right way.
> A task as simple as filing and stroking shapes is quite complicated because of X's bizarre pixel-oriented imaging rules.
Here's the thing: When XRender was added, it introduced a whole new set of framebuffer configuration options. It is these options that allow one to specify antialiasing modes and it's the very same options that also have to be used if one want to use OpenGL multisample antialiasing on a window facing framebuffer (without a multisampled window format the only way to get MSAA with OpenGL is to create a multisampled OpenGL framebuffer object render-target and perform multisampling resolution via framebuffer blitting).
The point is: It would have been trivial and perfectly allowed to alter the rasterization specification for X core drawing primitives in case a multisampled framebuffer configuration was active for the window. Replacing drawing behavior is something perfectly normal when introducing new OpenGL features (either by new version or extension) and the very same would have worked just as fine for X core.
if( fbconfig.multisampled ) {
draw_Xcore_primitives_with_new_antialiased_rules(...);
} else {
draw_Xcore_primitives_with_traditional_rules(...);
}
Note that if you want to replace X11 with something sensible, you're preaching to the choir. I've been advocating the use of abstract display systems, that are graphics primitive oriented (instead of pixel oriented) for years (actually over a decade now). But I've also found that many proponents and opponents of X11/Wayland/etc. do not actually understand the problem at all.
All of that beautiful free open source rendering code was originally conceived in the master bedroom of its parent's house, the X11 server. Its parents had ambitious but traditional plans for it, from the time it was only one bit deep, and as it grew up and learned how to walk around on eight bits with the help of a colormap.
Then when it finally reached puberty and learned how to composite 24 bit images into deep visuals, it needed more space and some privacy of its own, and room to store its growing collection of pixels, so its parents moved it into the X Rendering extension in the basement.
But it still had to share a single telephone line with its parents, who monitored all of its communications and screened its friends, while insisting it do all its chores like taking out the garbage and cleaning its buffers, before going out and playing with its friends.
It managed to open up a shared memory window into the back yard, so it could move larger quantities of pixels and cache back and forth between its local clients and its room in the basement, without waking up its parents in the middle of the night.
But as it grew up, it started dealing more and more little packets of pixels with its local clients on the side, and going away on frequent rides to make deliveries to remote clients, so its parents became suspicious and angry.
This caused many problems, but managed to work for a while. But then when it got older, it started getting invited to sleep over parties, where its friends and growing list of clients invited it to bring all its favorite pixels to their house to share and mix together.
Eventually it was regularly performing as Master Compositor at huge parties, pumping out colorful house pixels with throbbing techno alpha channels, deep into the night and on into the early morning.
But that behavior caused terrible problems with its parents at home, who didn't approve of being out of the loop, but still having to foot the bill for its Frosted Flakes and AOL subscription.
Finally it got its shit together enough to move out of its parent's basement, and into a small shared library apartment in Cairo, so it could perform freelance jobs for its growing list of clients who didn't want any involvement with its parents. Now it could party with its friends and clients, without its parents knowing and interfering with its pursuit of happiness.
Its parents had some very old-fashioned parochial ideas about font rendering and naming. They firmly believed that a font's place was in the pixmap, angrily hated the ideas of mixed alpha antialiasing or same alpha transparency, approved of the missionary transform but were otherwise affine-transphobic, and they sternly disapproved of outline fonts with soft voluptuous curves and gentle antialiased edges.
But with its new found maturity and hard earned freedom, it got lucky enough to hook up with a sexy outline font rendering stripper named Crystal FreeType and an elegant internationally suave text layout pole dancer named Paris Pango. As a free software threesome, together they integrated seamlessly, worked beautifully, hooked up with prolific scripts and toolkits, and painted some truly epic scenes.
As their careers advanced, they were employed in many important high profile jobs, including as Art Director of the renowned GTK+ Disco Dance Party (the Soul Train of the Desktop, syndicated to a long list of platforms and scripting languages), and MC (Master Compositor) of the internationally televised Mozilla Firefox Web Surfing Variety Show (based on the original Solid Gold Netscape show, that inspired all the others).
Not only did they cover other famous artist's works like HTML, CSS, SVG, PDF and XUL, but they also showcased their own instant-classic Canvas API, which revolutionized the world wide web and matured from a popular fad into an essential institution used by everyone around the world.
So at this point in history, there's really no point in asking such successful code to go back and live in its parent's basement again, because its style would be cramped, and nobody would want to visit it there, now that it finally has its own rich interesting life to live in the real world. ;)
But like all stories, also this one has a twist for the dark: Although the art created by the protagonist was of high quality, the artists technique was behind the curve of what people actually wanted to see. The sad thins is, people didn't exactly know what the wanted to see, unless it was shown to them. Also our protagonist artist had a obsessive preference for his drawing substrates: The only canvases he'd be drawing on would consist of orthogonal grids and would only fill each cell with a solid color. His sidekick Crystal Freetype was okay with it, but also figured, that some people, for some reason liked it, if she tripled the resolution of the grid in one direction and biased the hues by a periodic red-green-blue pattern. But she never got really perfect at it.
Some say, and those would clearly be right, that the reason for that was, that the people who'd wanted to see their art would do it only at galleries: But those galleries had problems with reproducing their illumination. Each gallery had slightly different light. For a long time each gallery tried to compensate with its own tools, documenting what had to be done in a customary way. Eventually all these galleries got their act together and agreed on a specific way to tell each other and the artist how the light looks at their place.
They also realized that for maximum effect the light at the gallery had to be taken into account when drawing the pictures.
Unfortunately our hero "rendering code" never properly learnt what to make out of the information he got from the gallieries. He preferred to work with his preferred colours Red, Green and Blue and knew how to mix them according to the color theory on RGB colors "s" as laid down by his idol "Adobe" (also called sRGB), but Crystal FreeType never got the knack for it, messing up the Gamma of her antialiasing. There would have been of course the color theory of linear contact color spaces, but our hero abhorred the idea to work with "imaginary" colors, or that the dyes in his paints would only look right after being treated with a colorspace-converting developer.
Sometimes two galleries would want to exhibit the same picture. Or one gallery one part and another gallery the other part; or maybe three or four libraries. Of course our hero could have carefully planned how to draw each part of his paintings, but this would take time and more importantly much more extra effort in dealing with his clients. So instead most of the time he'd just draw for the lowest common denominator. The pictures would be not as pretty as they could have been, but at least everybody got to see something.
But what really dragged down our hero was, that his paintings were heavy. Moving them around in towns where his clients lived already was hard work, but it was manageable, thanks to the heavy dutry transport system available. But sometimes a gallery away from his clients wanted to show the pictures and then it got really messy.
Some clients remembered that when "hero rendering code" still lived at his parents, he could give his parents a call and place an order for a picture to be drawn. He'd just telephone what it should look like, which went rather quickly. Of course some clients adopted a inefficient way of placing their orders, stating one item, asking if it was on the list then asking for the next one, and so on. Other clients became clever and just placed their whole order before asking back; often "hero rendering code" would already be at work, when the confirmation on the order arrived. Of course there would have still be problem of moving the picture to a gallery… but as it turns out the parents had a huge library with reconfigurable walls at their house. So clients who'd just want to show drawings drawn by "hero render code" at his parents libraries according to their telephone calls could do this from practically everywhere, even over telephone lines that could barely carry a conversation, yet patrons would see the same image quality.
But now with "hero rendering code" insisting on doing his work in the clients town transporting the pictures became a major issue. Some clients found the services of the Shrinker Codec Union; their union workers would deconstruct the drawings of "hero rendering code", sweep things under the rug they's presume the patrons would never see and transport that. For very complicated images they figured out, that this was actually faster than trying to talk the complicated picture through the telephone line; yet the price was, that pictures often suffered in their colour brilliance. It was however Crystal FreeType who's be extremely outraged, because it was often her expertly crafted contributions which got mauled by the Shrinker Coded Union workers.
Meanwhile new drawing tools appeared on the market; or rather they've been on the market for quite some time, but hero rendering code never learnt how to peoperly use them. His parents added an annex to their house though where those drawing tools could be used. But often it were hero rendering codes clients who'd then use these tools for their own means. Hero rendering code often tried to get to grip with those tools but often failed miserably; maybe hell never learn. And Crystal FreeType, she doesn't even understand how to use these tools properly; FreeType lais out her pictures and spans of lines, she'd colour in particular colors. But those new tools, if they are used like that produce poor results or it takes much longer to get a nice picture of a character, than using the old tools. But it's not that this is impossible. New artists who are expert in the use of these new tools have become runners up.
But many of hero rendering code's clients are now so closely tied to him, that they can't make use of those new expert drawers services. And they remember the times, when they could give the parent's "X11" a house call and have them write down the order for the picture.
Wouldn't it maybe be possible to create a lodging home and gallery for all these new artists in town, where one could place house calls for showing their drawings on premises? In a Gallery where the artists can paint the interesting parts of their painting in the room where they're going to be shown, matched to the lighting conditions then and there? Without the need to haul havy paintings over land?
to be continued…