GDK contains back-ends to X11, Wayland, Broadway (HTTP), Quartz and GDI and relies on Cairo for the rendering. Its new scene graph (canvas) is work-in-progress, its arrival should herald GTK 4.0.
GTK is implemented on top of an abstraction layer called GDK, freeing GTK from low-level concerns like input gathering, Drag and drop and pixel format conversion. GDK is an intermediate layer which separates GTK from the details of the windowing system.
GDK is an important part of GTK's portability. Since low-level cross-platform functionality is already provided by GLib, all that is needed to make GTK run on other platforms is to port GDK to the underlying operating system's graphics layer. Hence, the GDK ports to the Windows API and Quartz are what enable GTK applications to run on Windows and macOS, respectively.
Starting with GTK+ 2.8, GDK supports Cairo which should be used with GTK+ 3 instead of GDK's drawing functions.[1]
GDK is an intermediate layer which isolates GTK from the details of the windowing system. GDK is a thin wrapper around Xlib. The X Window System comes with a low-level library called Xlib. Almost every function in GDK is a very thin wrapper around a corresponding Xlib function; but some of the complexity (and functionality) of Xlib is hidden, to simplify programming and to make GDK easier to port to other windowing systems, such as Wayland or Microsoft Windows. The concealed Xlib functionality will rarely be of interest to application programmers; for example, many features used solely by window managers are not exposed in GDK.
GDK lets you do low level stuff, like e.g. "blit this pixmap to the screen".
GDK provides a layer that is much more portable than say the X protocol, without sacrificing any of the low-level accessibility that systems such as X provide. The true power of this abstraction is that if you choose to use it rather than say, X, your software will automatically render on the Linux Framebuffer and Windows.
Having OpenGL (or OpenGL ES) support in GDK, facilitates a slightly better control of the graphics pipeline; OpenGL is well suited for compositing textured data but totally unsuited for drawing.
While GTK applications remain mainloop driven (cf. Glib event loop), meaning the application is idle inside this main loop most of the time and just waits for something to happen and then calls the appropriate subroutine when it does, GdkFrameClock adds an additional mechanism, that gives a "pulse" to the application. It tells the application when to update and repaint a window.[3] The beat rate can be synchronized with the monitor refresh rate.
Developers were also considering new directions for the library, including removing deprecated API components and adding an integrated scene graph (canvas) system, similar to the Clutter graphics library, effectively integrating GTK with OpenGL and Vulkan.[4][5]
GTK+ Scene Graph Kit (GSK) was released as part of GTK+ 3.90 in March 2017. It is the scene graph and rendering API for GTK. GSK has not been further integrated with GDK (which is also part of GTK) but is kept in its own directory.
With the release of GNOME 3.16 in March 2015, GDK obtained an experimental back-end for the Mir display server protocol.[8] The Mir display server protocol is a product by Canonical for their Ubuntu distribution of Linux, which they intend to compete with the Wayland display server protocol; so far, it is implemented only in Ubuntu.
To start an application and force this instance of it to use a certain windowing system, you specify the variable GDK_BACKEND: GDK_BACKEND=wayland gnome-calculator GDK_BACKEND=wayland CLUTTER_BACKEND=wayland cheese
gdk-pixbuf
gdk-pixbuf is a toolkit for image loading and pixel buffer manipulation. The library provides image loading and saving facilities, fast scaling and compositing of pixbufs, simple animation loading (i.e. animated GIFs), and rendering the libart image buffer to a GdkDrawable instance.
gdk-pixbuf has a fairly large API.
The fundamental structure in the gdk-pixbuf library is GdkPixbuf, a private, opaque data structure that mirrors many of the same concepts that ArtPixBuf supports. In fact, most of GdkPixbuf's private data fields have the same names and data types as the corresponding ones in ArtPixBuf. This similarity dates back to the earlier days when gdk-pixbuf was a wrapper around libart. Since that time, the libart dependency has been stripped out, and gdk-pixbuf was merged into the GTK+ 2.0 code base. As such, gdk-pixbuf's days as a standalone library are limited to the GNOME 1 release.
With the release of GTK+ 2.22 on 2010-09-23, gdk-pixbuf has been turned back into a standalone library, after being shipped as part of GTK+ since gtk+ 2.0. This was done in preparation for the transition to GTK+ 3.
