GTK 2 and general Linux graphics performance analysis

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 9
PoorBest 

The Linux graphics stack

As stated above, applications nowadays don't talk to hardware directly, but use a common API (application programming interface) to draw to the screen. A simplified vision of the current Linux graphics stack is below:

Linux graphic stack

Think about this: the above diagram is a simplified, high-level representation of the various layer that a drawing command must traverse before hitting the hardware (which actually draw pixels on the screen). Without doubt the graphics stack is quite complex and, so, it can be quite heavy to manage.

From this diagram you can see that the applications use GTK 2 API to create high-level object (eg: windows, buttons, etc) and that, in turn, the GTK 2 API use a GTK 2 engine to draw these object with the required attribute (ie: color gradients, shapes, etc.). To accomplish its task, the GTK 2 engine can either directly use a lower-level API, the X11 API provided by Xlibs, or dispatch some commands to two other components, Cairo (for vector graphics) and Pango (for advanced text rendering). However, the final collector remain the X11 API, as Cairo use the facilities provided by Xlibs to do the real rendering (note: Cairo can use different rendering backend, for example OpenGL or Postscript, so it isn't necessarily connected to Xlibs, but usually it is).

At this point, the Xlibs convert draw instruction in X11 commands that are redirected to X11 server. Normally the X11 server runs on the same machine, but it is absolutely possible to have applications/GTK/Xlibs running on a machine and the X11 server on another. In this latter case, Xlibs encapsulate X11 commands into TCP packets and send them to X11 server (and vice-versa).

Finally, by using its graphics driver, the Xserver talk to the hardware to effectively draw the images (note: between the Xserver and the hardware there are other abstraction levels imposed by the kernel and by the driver model, but these low-level detail are beyond the scope of this article).

So, it come with no surprise that the optimization of the middle (green) layers have a great influence on the final rendering speed. But what is the current state of the GTK 2 and companion libraries on Linux? In very simple words, they are fast or slow?

The following benchmarks will try to reply to these questions...

You have no rights to post comments