Talk:GTK Scene Graph Kit

Explanation of used abbreviations

fbo = Framebuffer Object = https://www.khronos.org/opengl/wiki/Framebuffer_Object vao = Vertex Array Object = https://www.khronos.org/opengl/wiki/Vertex_Specification#Vertex_Array_Object

Dependencies on external libraries

• graphene: https://github.com/ebassi/graphene thin layer of types for graphic libraries
• libepoxy: https://github.com/anholt/libepoxy handling OpenGL function pointer management (being used instead of OpenGL Extension Wrangler Library (GLEW))

User:ScotXW^t@lk 09:43, 4 January 2018 (UTC)

Internal stuff

GskRenderer is a class that renders a scene graph. A scene graph consists of a tree of instances of GskRenderNode.

• An instance of #GskRenderer is typically used with a #GdkDrawingContext, which is associated to a GdkWindow.

Additionally, each rendering path has its own renderer implementation:

• gskcairorenderer.c (acts as the fallback)
• gskvulkanrenderer.c
• gskglrenderer.c
• gskbroadwayrenderer.c

#GdkWindow used to be a wrapper around an X11 window, and it used to be necessary for every widget to have its own GdkWindow! The issues with that, namely the excessive IPC with the X server, was mitigated in GTK+ 2.18, when many of those GdkWindows were turned into client side windows, but it is only in GTK+ 4.x, that we got rid of the necessity of each widget to have its own GdkWindow. In hits talk "Ding dong, GdkWindow is dead" at GUADEC 2017, Carlos Garnacho explained why this came to be.

GtkCssNode In GTK+4 every widget is/has a single CSS node, all properties apply. It should contain no other CSS nodes, in case such are required, they should belong to other widgets. CSS nodes are the backbone of the GtkStyleContext implementation and replace the role that GtkWidgetPath played in the past.

1. 2010-12-04 The struct "GtkStyleRegion" was added to gtkstylecontext.c
2. 2010-12-04 GtkStyleRegion was renamed to GtkStyleInfo, as it doesn't really have much to do with regions itself, the information it contains does. This struct is used in save/restore.
3. 2015-01-07 GtkStyleInfo was renamed to GtkCssNode (no explanation given, maybe there is correlation with DRM-Render-Nodes by David Herrmann?)
4. 2015-03-18 The struct GtkCssNode was moved from gtkstylecontext.c into its own file gtkcssnode.c, as the functionality of it is supposed to grow
5. 2015-03-18 Turn GtkCssNode into a GObject, as this will allow to create subclasses
6. 2015-03-18 Split into 3 objects:
   • GtkCssWidgetNode – for style contexts owned by a widget
   • GtkCssPathNode – for style contexts using a GtkWidgetPath
   • GtkCssTransientNode – for nodes created with gtk_style_context_save()/restore()
7. …
8. 2018-01-04 gtkcssnode.c has indeed grown substantially