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. 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 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 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.
GdkFrameClock
GdkFrameClock was added in GTK 3.8 While GTK applications remain mainloop driven, 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. The beat rate can be synchronized with the monitor refresh rate.
GTK Scene Graph Kit
In its history GDK contained and linked with a couple of different Canvases.
Developers were also considering new directions for the library, including removing deprecated API components and adding an integrated scene graph system, similar to the Cluttergraphics library, effectively integrating GTK with OpenGL and Vulkan.
GTK Scene Graph Kit
GTK+ Scene Graph Kit 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 but is kept in its own directory.
Windowing systems
GDK contains back-ends to a couple of windowing systems, namely to the X11 and Wayland protocols, to Quartz and GDI, and even to the Hypertext Transfer Protocol engine Broadway. With the release of GNOME 3.16 in March 2015, GDK obtained an experimental back-end for the Mir display server protocol. The Mirdisplay 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. At present, no back-end exists for KMS. To start an application and force this instance of it to use a certain windowing system, you specify the variable GDK_BACKEND:
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, 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.x 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.
https://git.gnome.org/browse/gdk-pixbuf/
The first stand-alone release was on 2010-Sep-21, its development started with on 2010-06-23. The latest release of gdk-pixbuf is from 2017-Oct-02. The development of 3.36 started with on 2016-04-26.
