Modern operating systems are very complex piece of software: the provide many integrated functionalities, wrapping them onto a very nice desktop environment. In the latest years, advancements in computer speed let developers concentrate more on the realization of a consistent, easy-to-use and very attractive graphical user interfaces (GUIs), with many eye-candy effects turned on by default.
However, while in the latest years aggregate computer speed (throughput) has steady increased more or less at the rate predicted by the Moore law (note: this law primary refers to the number of integrated transistors, but I see it used everywhere as a performance meter also) single thread performance (latency) did not have this radical performance increment. This means that complex, mostly single thread applications as the GUI and, by extension, the entire graphical stack have to be very careful about their speed: if the user feel the GUI and/or other graphics slow, he will have a quite bad experience using the machine.
So, a fast and responsive GUI and graphics system are of the utmost importance for a comfortable use of a desktop computer. On the other hand, this kind of applications are quite hard to program, because the hardware give you no facilities to create nice graphics. So, while in the old days (20 years ago) GUIs and OS graphics were programmed in assembly language, today the hardware is abstracted under various libraries levels.
This means that the OS and libraries designers have to do a trade-off: hide the hardware under too many, too complex abstraction levels and you will have an easy-to-program but slow graphics system. Use too simplistic abstractions and you will end with a very fast but very hard to program graphics system.
One of the most popular (if not the most popular) graphical toolkit used in open source projects is the Gimp Tool Kit version 2 – GTK 2 in short. While GTK3 is just around the corner, GTK 2 is and will remain for some time the graphical toolkit of choice. While it has many advanced and useful features, it is sometime regarded as over-engineered and a little slow. The net consequence is that sometime Linux application can be felt a little sluggish compared to Microsoft Windows and Apple Mac OS X equivalents (Firefox user interface is a good example).
However, GTK 2 look and feel can be customized quite heavily by using different themes and themes engines, with direct performance implications. So, it is possible that the alleged slowness depend on the GTK theme used rather than other factors? If not, where are the performance bottlenecks of today's Linux graphical stack?
In this article we will try to answer to these questions, or at least to give you some educated hints.
We will start with a simple and quick recap of the current Linux graphics stack.