1. 21 Sep, 2015 1 commit
  2. 13 Apr, 2015 1 commit
  3. 24 Nov, 2014 1 commit
    • Matthias Clasen's avatar
      Make scale=2 work again · c1ca7986
      Matthias Clasen authored
      There was a leftover HAVE_CAIRO_SURFACE_SET_DEVICE_SCALE ifdef
      that broke things, now that we don't use this define anymore.
  4. 20 Nov, 2014 3 commits
  5. 10 Nov, 2014 1 commit
  6. 08 Nov, 2014 2 commits
  7. 04 Nov, 2014 1 commit
    • Matthias Clasen's avatar
      Make window scale changes work again · 113e1d1d
      Matthias Clasen authored
      Commit afd9709a made us keep impl window
      cairo surfaces around across changes of window scale. But the
      window scale setter forgot to update the size and scale of the
      surface. The effect of this was that toggling the window scale
      from 1 to 2 in the inspector was not causing the window to draw
      at twice the size, although the X window was made twice as big,
      and input was scaled too. Fix this by updating the surface when
      the window scale changes.
  8. 30 Oct, 2014 1 commit
  9. 27 Oct, 2014 1 commit
  10. 23 Oct, 2014 1 commit
  11. 13 Oct, 2014 2 commits
    • 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
    • Jasper St. Pierre's avatar
      gdkwindow-x11: Fix graphical regression from 5e325c4 · ea21c456
      Jasper St. Pierre authored
      Before 5e325c4, the default BitGravity was NorthWestGravity.
      When static gravities were removed in 5e325c4, the BitGravity regressed
      to the X11 default, Forget. Forget causes giant graphical glitches and
      black flashes when resizing, especially in some environments that aren't
      synchronized to a paint clock yet, like XWayland.
      I'm assuming that the author assumed that the default of BitGravity was
      NorthWestGravity, which is the default of WinGravity. Just go ahead and
      fix this regression to make resizing look smooth again.
  12. 06 Oct, 2014 1 commit
    • Benjamin Otte's avatar
      gdk: Deprecate static gravities · 5e467209
      Benjamin Otte authored
      ... and remove all implementations. The API allows to not work "if the
      server doesn't support it. So from now on, no server does!
  13. 05 Oct, 2014 2 commits
  14. 02 Oct, 2014 1 commit
  15. 01 Oct, 2014 1 commit
    • Matthias Clasen's avatar
      Don't emit a useless warning · 52c91315
      Matthias Clasen authored
      The warning may have had some value at some point, but if
      people uninstall large icons just to make the warning go
      away, it does more harm than good. So just remove it.
  16. 05 Sep, 2014 1 commit
  17. 14 Jul, 2014 1 commit
  18. 22 Jun, 2014 1 commit
  19. 21 Jun, 2014 1 commit
    • Jasper St. Pierre's avatar
      gdkwindow: Remove the internal cairo_surface used for out-of-band painting · d48adf9c
      Jasper St. Pierre authored
      Traditionally, the way painting was done in GTK+ was with the
      "expose-event" handler, where you'd use GDK methods to do drawing on
      your surface. In GTK+ 2.24, we added cairo support with gdk_cairo_create,
      so you could paint your graphics with cairo.
      Since then, we've added client-side windows, double buffering, the paint
      clock, and various other enhancements, and the modern way to do drawing
      is to connect to the "draw" signal on GtkWidget, which hands you a
      cairo_t. To do double-buffering, the cairo_t we hand you is actually on
      a secret surface, not the actual backing store of the window, and when
      the draw handler completes we blit it into the main backing store
      The code to do this is with the APIs gdk_window_begin_paint_region,
      which creates the temporary surface, and gdk_window_end_paint which
      blits it back into the backing store. GTK+'s implementation of the
      "draw" signal uses these APIs.
      We've always sort-of supported people calling gdk_cairo_create
      "outside" of a begin_paint / end_paint like old times, but then you're
      not getting the benefit of double-buffering, and it's harder for GDK to
      Additionally, newer backends like Mir and Wayland can't actually support
      this model, since they're based on double-buffering and swapping buffers
      at various points in time. If we hand you a random cairo_t, we have no
      idea when is a good time to swap.
      Remove support for this.
      This is technically a GDK API break: a warning is added in cases where
      gdk_cairo_create is called outside of a paint cycle, and the returned
      surface is a dummy that won't ever be composited back onto the main
      surface. Testing with complex applications like Ardour didn't produce
      any warnings.
  20. 22 May, 2014 4 commits
  21. 21 May, 2014 1 commit
    • Jasper St. Pierre's avatar
      gtkwindow: Use window-manager-side window menus · 0ea1a526
      Jasper St. Pierre authored
      This avoids a bunch of policy problems with deciding how to lay
      out the window menu under different WMs.
      For now, we use the special event _GTK_SHOW_WINDOW_MENU, but we
      hope to have this standardized in wm-spec quite soon, as KDE wants
      it as well.
  22. 17 Mar, 2014 4 commits
  23. 28 Feb, 2014 1 commit
  24. 25 Feb, 2014 1 commit
  25. 19 Feb, 2014 1 commit
  26. 13 Feb, 2014 1 commit
  27. 07 Feb, 2014 2 commits
  28. 04 Feb, 2014 1 commit