1. 06 Feb, 2018 1 commit
    • Matthias Clasen's avatar
      The big versioning cleanup · 4c150d8e
      Matthias Clasen authored
      Remove all the old 2.x and 3.x version annotations.
      GTK+ 4 is a new start, and from the perspective of a
      GTK+ 4 developer all these APIs have been around since
      the beginning.
  2. 21 Dec, 2017 1 commit
  3. 03 Nov, 2017 1 commit
  4. 28 Oct, 2017 1 commit
  5. 23 Dec, 2016 2 commits
    • Benjamin Otte's avatar
      gsk: Add gsk_renderer_render_texture() · 373e08d6
      Benjamin Otte authored
      ... and implement it for the Cairo renderer.
      It's an API that instructs a renderer to render to a texture.
      So far this is mostly meant to be used for testing, but I could imagine
      it being useful for rendering DND icons.
    • Benjamin Otte's avatar
      gsk: Remove nonexisting functions · 814b66e1
      Benjamin Otte authored
      The function was removed when gsk_render_node_draw() was and
      gsk_renderer_realize() was refactored respectively.
  6. 20 Dec, 2016 1 commit
  7. 05 Dec, 2016 2 commits
  8. 30 Nov, 2016 3 commits
  9. 01 Nov, 2016 1 commit
  10. 18 Oct, 2016 9 commits
    • Emmanuele Bassi's avatar
      gsk: Bump up all version annotations · 69781c25
      Emmanuele Bassi authored
      GSK is part of the 4.0 development cycle.
    • Emmanuele Bassi's avatar
      gsk: Add the ability to create fallback renderers · dace0791
      Emmanuele Bassi authored
      While porting GTK to GskRenderer we noticed that the current fallback
      code for widgets using Cairo to draw is not enough to cover all the
      possible cases.
      For instance, if a container widget still uses GtkWidget::draw to render
      its children, and at least one of them has been ported to using render
      nodes instead, the container won't know how to draw it.
      For this reason we want to provide to layers above GSK the ability to
      create a "fallback" renderer instance, created using a "parent"
      GskRenderer instance, but using a Cairo context as the rendering target
      instead of a GdkDrawingContext.
      GTK will use this inside the gtk_widget_draw() implementation, if a
      widget implements GtkWidgetClass.get_render_node().
    • Emmanuele Bassi's avatar
      gsk: Remove GskRenderer:auto-clear · 7de49fb7
      Emmanuele Bassi authored
      We control the clearing inside each GskRenderer implementation, and we
      don't allow providing a target surface any more.
    • Emmanuele Bassi's avatar
      gsk: Remove :use-alpha from GskRenderer · f764d03c
      Emmanuele Bassi authored
      It's unused, and we always assume we render with an alpha channel
      enabled because it's 2016.
    • Emmanuele Bassi's avatar
      gsk: Move scaling filters to GskRenderNode · 387ed37f
      Emmanuele Bassi authored
      The renderer will always use nearest-neighbor filters because it renders
      at 1:1 pixel to texel ratio.
      On the other hand, render nodes may be scaled, so we need to offer a way
      to control the minification and magnification filters.
    • Emmanuele Bassi's avatar
      gsk: Drop modelview/projection from GskRenderer API · ce673365
      Emmanuele Bassi authored
      The details of the modelview and projection matrices are only useful for
      the GL renderer; there's really no point in having those details
      available in the generic API — especially as the Cairo fallback renderer
      cannot really set up a complex modelview or a projection matrix.
    • Emmanuele Bassi's avatar
      gsk: Tie render nodes to renderers · 3d90a070
      Emmanuele Bassi authored
      Render nodes need access to rendering information like scaling factors.
      If we keep render nodes separate from renderers until we submit a nodes
      tree for rendering we're going to have to duplicate all that information
      in a way that makes the API more complicated and fuzzier on its
      By having GskRenderer create GskRenderNode instances we can tie nodes
      and renderers together; since higher layers will also have access to
      the renderer instance, this does not add any burden to callers.
      Additionally, if memory measurements indicate that we are spending too
      much time in the allocation of new render nodes, we can now easily
      implement a free-list or a renderer-specific allocator without breaking
      the API.
    • Emmanuele Bassi's avatar
      gsk: Rework GskRenderer and GskRenderNode semantics · 074c77e7
      Emmanuele Bassi authored
      This commit changes the way GskRenderer and GskRenderNode interact and
      are meant to be used.
      GskRenderNode should represent a transient tree of rendering nodes,
      which are submitted to the GskRenderer at render time; this allows the
      renderer to take ownership of the render tree. Once the toolkit and
      application code have finished assembling it, the render tree ownership
      is transferred to the renderer.
    • Emmanuele Bassi's avatar
      Initial implementation of GSK rendering pipeline · 7afdd3fd
      Emmanuele Bassi authored
      GSK is conceptually split into two scene graphs:
       * a simple rendering tree of operations
       * a complex set of logical layers
      The latter is built on the former, and adds convenience and high level
      API for application developers.
      The lower layer, though, is what gets transformed into the rendering
      pipeline, as it's simple and thus can be transformed into appropriate
      rendering commands with minimal state changes.
      The lower layer is also suitable for reuse from more complex higher
      layers, like the CSS machinery in GTK, without necessarily port those
      layers to the GSK high level API.
      This lower layer is based on GskRenderNode instances, which represent
      the tree of rendering operations; and a GskRenderer instance, which
      takes the render nodes and submits them (after potentially reordering
      and transforming them to a more appropriate representation) to the
      underlying graphic system.