1. 15 Aug, 2017 1 commit
  2. 06 Aug, 2017 1 commit
  3. 20 Oct, 2016 1 commit
  4. 22 Sep, 2016 1 commit
  5. 08 Sep, 2016 1 commit
  6. 26 May, 2016 1 commit
  7. 23 May, 2016 1 commit
  8. 18 May, 2016 1 commit
    • Olivier Fourdan's avatar
      display: Add vfunc for get_monitor_at_window · d288a134
      Olivier Fourdan authored
      Some backends (namely Wayland) do not support global coordinates so
      using the window position to determine the monitor will always fail on
      such backends.
      
      In such cases, the backend itself might be better suited to identify
      the monitor a given window resides on.
      
      Add a vfunc get_monitor_at_window() to the display class so that we can
      use the backend to retrieve the monitor, if the backend implements it.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=766566
      d288a134
  9. 01 May, 2016 1 commit
  10. 28 Apr, 2016 2 commits
    • Matthias Clasen's avatar
      Add a fallback for unconverted backends · b6c4ba0e
      Matthias Clasen authored
      If the monitor vfuncs are not implemented in a display class,
      fall back to providing a single monitor object representing
      the entire screen. This is not meant to be 'good enough', it
      is just to provide some implementation until all backends
      implement the monitor vfuncs. When that is the case, the
      fallback should be removed.
      b6c4ba0e
    • Matthias Clasen's avatar
      display: Add new monitor apis · 9d719b99
      Matthias Clasen authored
      This follows our general direction of moving functionality
      from GdkScreen to GdkDisplay.
      9d719b99
  11. 29 Feb, 2016 3 commits
  12. 28 Feb, 2016 2 commits
  13. 26 Feb, 2016 1 commit
  14. 16 Dec, 2015 2 commits
  15. 14 Dec, 2015 3 commits
  16. 27 Oct, 2015 1 commit
  17. 01 Aug, 2015 1 commit
    • Matthias Clasen's avatar
      Code cleanup · 9f24b547
      Matthias Clasen authored
      Use g_slist_free_full more consistently. This commit just converts
      the obvious cases where g_slist_forall is directly followed by
      g_slist_free.
      9f24b547
  18. 10 Nov, 2014 3 commits
  19. 08 Nov, 2014 1 commit
    • Emmanuele Bassi's avatar
      Make global GDK libgtk_only functions more private · eedbec20
      Emmanuele Bassi authored
      The current way of exposing GDK API that should be considered internal
      to GTK+ is to append a 'libgtk_only' suffix to the function name; this
      is not really safe.
      
      GLib has been using a slightly different approach: a private table of
      function pointers, and a macro that allows accessing the desired symbol
      inside that vtable.
      
      We can copy the approach, and deprecate the 'libgtk_only' symbols in
      lieu of outright removal.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=739781
      eedbec20
  20. 30 Oct, 2014 1 commit
  21. 28 Oct, 2014 1 commit
  22. 13 Oct, 2014 2 commits
    • Alexander Larsson's avatar
      gl: Make gdk_gl_context_make_current() return void · fdeb4f8c
      Alexander Larsson authored
      Its not really reasonable to handle failures to make_current, it
      basically only happens if you pass invalid arguments to it, and
      thats not something we trap on similar things on the X drawing side.
      
      If GL is not supported that should be handled by the context creation
      failing, and anything going wrong after that is essentially a critical
      (or an async X error).
      fdeb4f8c
    • Alexander Larsson's avatar
      gdk: Add support for OpenGL · 038aac62
      Alexander Larsson authored
      This adds the new type GdkGLContext that wraps an OpenGL context for a
      particular native window. It also adds support for the gdk paint
      machinery to use OpenGL to draw everything. As soon as anyone creates
      a GL context for a native window we create a "paint context" for that
      GdkWindow and switch to using GL for painting it.
      
      This commit contains only an implementation for X11 (using GLX).
      
      The way painting works is that all client gl contexts draw into
      offscreen buffers rather than directly to the back buffer, and the
      way something gets onto the window is by using gdk_cairo_draw_from_gl()
      to draw part of that buffer onto the draw cairo context.
      
      As a fallback (if we're doing redirected drawing or some effect like a
      cairo_push_group()) we read back the gl buffer into memory and composite
      using cairo. This means that GL rendering works in all cases, including
      rendering to a PDF. However, this is not particularly fast.
      
      In the *typical* case, where we're drawing directly to the window in
      the regular paint loop we hit the fast path. The fast path uses opengl
      to draw the buffer to the window back buffer, either by blitting or
      texturing. Then we track the region that was drawn, and when the draw
      ends we paint the normal cairo surface to the window (using
      texture-from-pixmap in the X11 case, or texture from cairo image
      otherwise) in the regions where there is no gl painted.
      
      There are some complexities wrt layering of gl and cairo areas though:
      * We track via gdk_window_mark_paint_from_clip() whenever gtk is
        painting over a region we previously rendered with opengl
        (flushed_region). This area (needs_blend_region) is blended
        rather than copied at the end of the frame.
      * If we're drawing a gl texture with alpha we first copy the current
        cairo_surface inside the target region to the back buffer before
        we blend over it.
      
      These two operations allow us full stacking of transparent gl and cairo
      regions.
      038aac62
  23. 12 Oct, 2014 1 commit
  24. 11 May, 2014 1 commit
  25. 19 Feb, 2014 1 commit
  26. 09 Feb, 2014 1 commit
  27. 07 Feb, 2014 2 commits
  28. 04 Feb, 2014 2 commits