5 ms·
> 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 som
by 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 agoYeah 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 agoAnd 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.
- datenwolf 10y ago> 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).
- digi_owl 10y agoForest, trees, good night.