1. 05 Jun, 2018 1 commit
    • Jonas Ådahl's avatar
      gdk: Make gdk_window_move_to_rect public · 9b3c745f
      Jonas Ådahl authored
      This is the API used by GtkMenu to properly position menus on the screen
      without requiring GTK to query the menu window's position or the work
      area of where the window is positioned. It makes it possible to position
      popup windows properly when using Wayland.
      
      Make this API available to external users so custom popup windows can be
      positioned properly as well.
      
      Closes: #997
      9b3c745f
  2. 11 Jan, 2017 1 commit
  3. 21 Oct, 2016 1 commit
  4. 20 Oct, 2016 1 commit
  5. 19 Jul, 2016 1 commit
  6. 09 Jun, 2016 3 commits
  7. 15 Dec, 2015 1 commit
  8. 25 Jul, 2015 1 commit
  9. 23 Jun, 2015 1 commit
  10. 15 Jun, 2015 1 commit
    • Alexander Larsson's avatar
      gdk: Add gdk_window_set_pass_through · 4c3eece6
      Alexander Larsson authored
      An pass_through window is something you can draw in but does not
      affect event handling. Normally if a window has with no event mask set
      for a particular event then input events in it go to its parent window
      (X11 semantics), whereas if pass_through is enabled the window below
      the window will get the event. The later mode is useful when the
      window is partially transparent. Note that an pass-through windows can
      have child windows that are not pass-through so they can still get events
      on some parts.
      
      Semantically, this behaves the same as an regular window with
      gdk_window_set_child_input_shapes() called on it (and re-called any
      time a child is changed), but its far more efficient and easy to use.
      
      This allows us to fix the testoverlay input stacking test.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=750568
      
      https://bugs.freedesktop.org/show_bug.cgi?id=90917
      4c3eece6
  11. 12 Feb, 2015 1 commit
  12. 09 Feb, 2015 1 commit
    • Emmanuele Bassi's avatar
      GL: Split GL context creation in two phases · 22e6f37c
      Emmanuele Bassi authored
      One of the major requests by OpenGL users has been the ability to
      specify settings when creating a GL context, like the version to use
      or whether the debug support should be enabled.
      
      We have a couple of requirements in terms of API:
      
       • avoid, if at all possible, the "C arrays of integers with
         attribute, value pairs", which are hard to write and hard
         to bind in non-C languages.
       • allow failing in a recoverable way.
       • do not make the GL context creation API a mess of arguments.
      
      Looking at prior art, it seems that a common pattern is to split the
      construction phase in two:
      
       • a first phase that creates a GL context wrapper object and
         does preliminary checks on the environment.
       • a second phase that creates the backend-specific GL object.
      
      We adopted a similar pattern:
      
       • gdk_window_create_gl_context() creates a GdkGLContext
       • gdk_gl_context_realize() creates the underlying resources
      
      Calling gdk_gl_context_make_current() also realizes the context, so
      simple GL users do not need to care. Advanced users will want to
      call gdk_window_create_gl_context(), set up the optional requirements,
      and then call gdk_gl_context_realize(). If either of these two steps
      fails, it's possible to recover by changing the requirements, or simply
      creating a new GdkGLContext instance.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=741946
      22e6f37c
  13. 08 Nov, 2014 1 commit
  14. 13 Oct, 2014 4 commits
    • Matthias Clasen's avatar
      Pedantic formatting fix · 7de9995f
      Matthias Clasen authored
      7de9995f
    • Matthias Clasen's avatar
      Correct Since tags · 7a80c3b0
      Matthias Clasen authored
      7a80c3b0
    • Alexander Larsson's avatar
      gdk: Add support for OpenGL · 038aac62
      Alexander Larsson authored and Matthias Clasen's avatar Matthias Clasen committed
      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
    • Alexander Larsson's avatar
      Add gdk_window_mark_paint_from_clip and call from widget drawing · d0147a6f
      Alexander Larsson authored and Matthias Clasen's avatar Matthias Clasen committed
      This is a new function that gets called every time we're drawing
      some area in the Gtk paint machinery. It is a no-op right now, but
      it will be required later to keep track of what areas which
      we previously rendered with GL was overwritten with cairo contents.
      d0147a6f
  15. 12 Oct, 2014 1 commit
  16. 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!
      5e467209
  17. 26 Aug, 2014 1 commit
  18. 21 Jun, 2014 1 commit
  19. 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.
      0ea1a526
  20. 07 Feb, 2014 3 commits
  21. 05 Feb, 2014 1 commit
  22. 04 Feb, 2014 1 commit
  23. 29 Jan, 2014 2 commits
  24. 14 Dec, 2013 1 commit
  25. 13 Dec, 2013 1 commit
  26. 09 Nov, 2013 1 commit
  27. 28 Aug, 2013 1 commit
  28. 03 Jul, 2013 3 commits
  29. 27 May, 2013 1 commit
  30. 07 May, 2013 1 commit
    • Alexander Larsson's avatar
      Add gdk_window_get_children_with_user_data · adffcf8a
      Alexander Larsson authored
      This function returns all the children that has a specific user_data set.
      This is used a lot in the new GtkWidget drawing code and doing
      it this way is faster than getting every child and calling get_user_data
      on each (which was a non-neglible part of the profiles). Additionally it
      also allows use to use some kind of hashtable to make this operation even
      faster if needed in the future.
      adffcf8a