Ancient X11 scaling technology

If I was to play Dark Souls 3 and/or Elden ring on Linux without tearfree. There is significant screen tearing and the game feels very choppy when playing.

To enable TearFree on Xorg. You typically make a new configuration file that sits in /etc/X11/xorg.conf.d/ and append to the X configuration

https://wiki.archlinux.org/title/AMDGPU#Tear_free_rendering

There are downside to this, but I would only imagine they are problems on older GPUs.

https://unix.stackexchange.com/questions/518362/whats-the-do...

I've never noticed these downsides personally and everything seems to work great.

I don't like Wayland. It still seems very buggy and I am running Debian Trixie and would prefer to keep using X11.

But IME Wayland does have higher performance on older hardware it seems than X. My old laptop could barely play Youtube with X11 (it is the video itself not YouTube being a resource hog, I checked), Wayland performance is much better.

I was doing this circa 2005 with an OpenGL program running on a Linux box in a server closet and a Windows machine running on my desk running some X11 server. Before I did that, I did research into the remote-draw capability of both X11 and OpenGL and came to the conclusion that what I eventually ended up doing would work just fine.

Finally (and for a long time now) it's an independent library, no longer tied into the X server and Xr extension, and there are a lot of wrappers for it, browser and GTK and many other frameworks use it, and it has lots of nice bindings to languages, like pycairo.

Jim Gettys, one of Cairo's authors and an original X-Windows architect, also worked on the OLPC project and its Sugar user interface framework (designed for making educational apps for kids), which used Cairo via GTK/PyGTK/PyCairo/Pango/Poppler.

Jim's big cause is that he champions eradicating "Bufferbloat":

https://en.wikipedia.org/wiki/Bufferbloat

https://gettys.wordpress.com/2010/12/03/introducing-the-crim...

I had a great time using it for the Micropolis (open source SimCity) tile rendering engine, which I wrote in C++, then wrapped with David Beazly's SWIG tool as a Python extension, so Python PyGTK apps could pass their existing Cairo rendering context into C++ and it could render at high speed without the Python interpreter in the way, on either windows or bitmaps.

https://en.wikipedia.org/wiki/SWIG

The TileEngine is a C++ python module wrapped with SWIG, that uses the Cairo library and knows how to accept a PyGTK Cairo context as a parameter to draw on directly via the api -- Python just passes pointers back and forth between PyGTK by wrangling and unwrangling wrappers around the Cairo context pointer:

TileEngine: https://github.com/SimHacker/micropolis/tree/master/Micropol...

tileengine.h: https://github.com/SimHacker/micropolis/blob/master/Micropol...

tileengine.cpp: https://github.com/SimHacker/micropolis/blob/master/Micropol...

pycairo.i: https://github.com/SimHacker/micropolis/blob/master/Micropol...

tileengine-swig-python.i: https://github.com/SimHacker/micropolis/blob/master/Micropol...

tileengine.i: https://github.com/SimHacker/micropolis/blob/master/Micropol...

Then you can call the tile engine from Python, and build GTK widgets and apps on top of it like so, and it all runs silky smooth, with pixel perfect tiling and scaling, so you can zoom into the SimCity map, and Python can efficiently draw sprites and overlays on it like Godzilla, tornados, trains, airplanes, helicopters, the cursor, etc:

tiledrawingarea.py: https://github.com/SimHacker/micropolis/blob/master/Micropol...

tilewindow.py: https://github.com/SimHacker/micropolis/blob/master/Micropol...

tiletool.py: https://github.com/SimHacker/micropolis/blob/master/Micropol...

I've written about Cairo on HN before, sharing some email with Jim about it:

https://news.ycombinator.com/item?id=20379336

DonHopkins on July 8, 2019 | parent | context | favorite | on: The death watch for the X Window System has probab...

Cairo wasn't the library behind the X11 drawing API, it was originally the Xr rendering extension, that was an alternative to the original X11 drawing API.

https://en.wikipedia.org/wiki/Cairo_(graphics)

>The name Cairo derives from the original name Xr, interpreted as the Greek letters chi and rho.

You're right, it doesn't actually make sense to put your drawing functions in the display server any more (at least in the case of X11, which doesn't have an extension language to drive the drawing functions -- but it did make sense for NeWS which also used PostScript as an extension language as well as a drawing API).

So Cairo rose above X11 and became its own independent library, so it could be useful to clients and toolkits on any window system or hardware.

https://www.osnews.com/story/3602/xr-x11-cross-device-render...

https://web.archive.org/web/20030805030147/http://xr.xwin.or...

https://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004...

Here's some email discussion with Jim Gettys about where Cairo came from:

From: Jim Gettys Date: Jan 9, 2007, 11:04 PM

The day I thought X was dead was the day I installed CDE on my Alpha.

It was years later I realized the young turks were ignoring the disaster perpetrated by the UNIX vendors in the name of "standardization"; since then, Keith Packard and I have tried to pay for our design mistakes in X by things like the new font model, X Render extension, Composite, and Cairo, while putting stakes in the heart of disasters like XIE, LBX, PEX, the old X core font model, and similar design by committee mistakes (though the broken core 2D graphics and font stuff must be considered "original sin" committed by people who didn't know any better at the time).

So we've mostly succeeded at dragging the old whale off the beach and getting it to live again.

From: Don Hopkins Date: Wed, Jan 17, 2007, 10:50 PM

Cairo looks wonderful! I'm looking forward to using it from Python, which should be lots of fun.

A lot of that old X11 stuff was thrown in by big companies to shill existing products (like using PEX to sell 3d graphics hardware, by drawing rotating 3-d cubes in an attempt to hypnotize people).

Remember UIL? I heard that was written by the VMS trolls at DEC, who naturally designed it with an 132 column line length limitation and no pre-processor of course. The word on the street was that DEC threw down the gauntlet and insisted on UIL being included in the standard, even though the rest of the committee hated it for sucking so bad. But DEC threatened to hold their breath until they got their way.

And there were a lot of weird dynamics around commercial extensions like Display PostScript, which (as I remember it) was used as an excuse for not fixing the font problems a lot earlier: "If you want to do readable text, then you should be using Display PostScript."

The problem was that Linux doesn't have a vendor to pay the Display PostScript licensing fee to Adobe, so Linux drove a lot of "urban renewal" of problems that had been sidelined by the big blundering companies originally involved with X.

>So we've mostly succeeded at dragging the old whale off the beach and getting it to live again.

Hey, that's a lot better than dynamiting the whale, which seemed like a such good idea at the time! (Oh the humanity!)

https://www.youtube.com/watch?v=AtVSzU20ZGk

From: Jim Gettys Date: Jan 17, 2007, 11:41 PM

> Cairo looks wonderful! I'm looking forward to using it from Python, which should be lots of fun.

Yup. Cairo is really good stuff. This time we had the benefit of Lyle Ramshaw to get us unstuck. Would that I'd known Lyle in 1986; but it was too late 3 years later when I got to know him.

https://cairographics.org/bibliography/

Here's some more of the discussion with Jim about Cairo and X-Windows:

https://news.ycombinator.com/item?id=7727953

>In 2007, I apologized to Jim Gettys for the tone of the X-Windows Disaster chapter I wrote for the book, to make sure he had no hard feelings and forgave me for my vitriolic rants and cheap shots of criticism:

http://www.donhopkins.com/home/catalog/unix-haters/x-windows...

DH>> I hope you founds it more entertaining than offensive!

JG> At the time, I remember it hurting; now I find it entertaining. Time cures such things. And Motif was definitely a vendor perpetrated unmitigated disaster: the worst of it was that it "succeeded" in unifying the UNIX gui, which means it succeeded at stopping all reasonable work on gui's on UNIX until the young Linux turks took over.

JG> And by '93 or so, the UNIX vendors actively wanted no change, as they had given up on the desktop and any innovation would cost them money.

DH>> The whole "Unix-Haters Handbook" thing was intended to shake up the status quo and inspire people to improve the situation instead of blindly accepting the received view. (And that's what's finally happened, although I can't take the credit, because it largely belongs to Linux -- and now that's the OLPC's mission!)

DH>> The unix-haters mailing list was a spin-off of its-lovers@mit-ai: in order to qualify for the mailing list you had to post a truly vitriolic no-holds-barred eyeball-popping flame.

DH>> I hope that helps to explain the tone of "The X-Windows Disaster", which I wrote to blow off steam while I was developing the X11 version of SimCity.

JG> Yup. I won't hold it against you ;-). Though any operating system with ddt as its shell is downright user hostile...

JG>>> The day I thought X was dead was the day I installed CDE on my Alpha. [...]

And more about Pango, the text rendering library on top of Cairo, the OLPC's Sugar user interface, which was built on PyGTK, and the OLPC Read book reader app that used the Cairo-based Poppler PDF rendering library:

https://en.wikipedia.org/wiki/Poppler_(software)

https://news.ycombinator.com/item?id=16852148

>I worked on making the Read activity usable in book mode (keyboard folded away, but gamepad buttons usable), and I vaguely recall putting in an ioctl to put the CPU to sleep after you turned a page, but I'm not sure if my changes made it in. [...]

>Sugar had a long way to go, and wasn't very well documented. They were trying to do too much from scratch, and choose a technically good but not winning platform. It was trying to be far too revolutionary, but at the same time building on top of layers and layers of legacy stack (X11, GTK, GTK Objects, PyGTK bindings, Python, etc).

>Sugar was written in Python and built on top of PyGTK, which necessitated buying into a lot of "stuff". On top of that, it used other Python modules and GTK bindings like Cairo for imaging, Pango for text, etc. All great industrial strength stuff. But then it had its own higher level Hippo canvas and user interface stuff on top of that, which never really went anywhere (for good reason: it was complex because it was written for PyGTK in a misshapen mish-mash of Python and C with the GTK object system, instead of pure simple Python code -- hardly what Alan Kay thinks of as "object oriented programming"). And for browser based stuff there were the Python bindings to xulrunner, which just made you yearn for pure JavaScript without all the layers of adaptive middle-ware between incompatible object systems.

>The problem is that Sugar missed the JavaScript/Web Browser boat (by arriving a bit too early, or actually just not having enough situational awareness). Sugar should have been written in JavaScript and run in any browser (or in an Electron-like shell such as xulrunner). Then it would be like a Chromebook, and it would benefit from the enormous amount of energy being put into the JavaScript/HTML platform. Python and GTK just hasn't had that much lovin'.

>When I ported the multi player TCL/Tk/X11 version of SimCity to the OLPC, I ripped out the multi player support because it was too low level and required granting full permission to your X server to other players. I intended to eventually reimplement it on top of the Sugar grid networking and multi user activity stuff, but that never materialized, and it would have been a completely different architecture than one X11 client connecting to multiple X11 servers.

>Then I made a simple shell script based wrapper around the TCL/Tk application, to start and stop it from the Sugar menus. It wasn't any more integrated with Sugar than that. Of course the long term plan was to rewrite it from the ground up so it was scriptable in Python, and took advantage of all the fancy Sugar stuff.

>But since the Sugar stuff wasn't ready yet, I spent my time ripping out TCL/Tk, translating the C code to C++, wrapping it with SWIG and plugging it into Python, then implementing a pure PyGTK/Cairo user interface, without any Sugar stuff, which would at least be a small step in the direction of supporting Sugar, and big step in the direction of supporting any other platform (like the web).

[...]

If you ever get really bored one day, and you have nothing else to do, and you're using AMD/ATi hardware, try enabling the TearFree option for your video card driver. Something like

  Section "Device"
   Identifier "AMD"
   Driver "amdgpu"
   Option "TearFree" "on"
  EndSection

My money is on Wayland enabling the equivalent of this setting by default.

> I presume there was some tradeoff which...

Did you notice any problems after enabling the setting? If you didn't notice any problems, then why would you care about any hypothetical tradeoffs?