Glamor, X11's OpenGL-Based 2D Acceleration Driver, Is Becoming Useful

The Glamor driver for X11 has sought for years to replace all of the GPU-specific 2D rendering acceleration code in X.org with portable, high performance OpenGL. Unfortunately, that goal was hampered by the project starting in the awkward time when folks thought fixed-function hardware was still worth supporting. But, according to Keith Packard, the last few months have seen the code modernized and finally maturing as a credible replacement for many of the hardware-specific 2D acceleration backends. From his weblog: "Fast forward to the last six months. Eric has spent a bunch of time cleaning up Glamor internals, and in fact he’s had it merged into the core X server for version 1.16 which will be coming up this July. Within the Glamor code base, he's been cleaning some internal structures up and making life more tolerable for Glamor developers. ... A big part of the cleanup was a transition all of the extension function calls to use his other new project, libepoxy, which provides a sane, consistent and performant API to OpenGL extensions for Linux, Mac OS and Windows." Keith Packard dove in and replaced the Glamor acceleration for core text and points (points in X11 are particularly difficult to accelerate quickly) in just a few days. Text performance is now significantly faster than the software version (not that anyone is using core text any more, but "they’re often one of the hardest things to do efficiently with a heavy weight GPU interface, and OpenGL can be amazingly heavy weight if you let it."). For points, he moved vertex transformation to the GPU getting it up to the same speed as the software implementation. Looking forward, he wrote "Having managed to accelerate 17 of the 392 operations in x11perf, it’s pretty clear that I could spend a bunch of time just stepping through each of the remaining ones and working on them. Before doing that, we want to try and work out some general principles about how to handle core X fill styles. Moving all of the stipple and tile computation to the GPU will help reduce the amount of code necessary to fill rectangles and spans, along with improving performance, assuming the above exercise generalizes to other primitives." Code is available in anholt's and keithp's xserver branches.

X network transparency is hardly useful anymore

[Anonymous Coward]

For everyone that disparages Wayland without really understanding anything about Wayland, which seems to be most everyone, I highly recommend listening to this talk by a core X.org developer:

http://www.youtube.com/watch?v... [youtube.com] [youtube.com]

TL;DR points:
- X11 is no longer "network transparent" and hasn't been so in a long time, due to reliance on DRI, Xrender, Xvideo, etc.
- X11 is already used in a manner that is similar to Wayland but with a very poor inter-process communication layer and synchronization issues, with most of X11's core bypassed (server-side fonts, drawing APIs, etc).
- X11 when used remotely is already like VNC, but very poor at it. Lots of round-trips, etc, all to show bitmaps.

In the end, there are a few things I need from Wayland, and I think they will be there in the end:
- app-based network transparency, not just remote desktop
- middle click paste. Maybe done with a virtual frame buffer and rdp to ship the final rendering across the wire.
- customizable focus policy (focus follows mouse, click to raise)
- user replaceable window/composite managers