1. 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
  2. 28 Apr, 2016 1 commit
  3. 29 Feb, 2016 2 commits
  4. 28 Feb, 2016 1 commit
  5. 24 Feb, 2016 1 commit
  6. 14 Dec, 2015 1 commit
  7. 10 Nov, 2014 2 commits
  8. 30 Oct, 2014 1 commit
  9. 27 Oct, 2014 1 commit
  10. 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
  11. 10 Jun, 2014 1 commit
  12. 13 Jan, 2014 1 commit
  13. 12 Nov, 2013 1 commit
    • Owen W. Taylor's avatar
      Handle recursion from motion event handlers · f50a3af1
      Owen W. Taylor authored
      If a motion event handler (or other handler running from the flush-events
      phase of the frame clock) recursed the main loop then flushing wouldn't
      complete until after the recursed main loop returned, and various aspects
      of the state would get out of sync.
      
      To fix this, change flushing of the event queue to simply mark events as
      ready to flush, and let normal event delivery handle the rest.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=705176
      f50a3af1
  14. 07 Aug, 2013 1 commit
  15. 19 Apr, 2013 1 commit
  16. 15 Apr, 2013 1 commit
  17. 02 Apr, 2013 1 commit
  18. 14 Feb, 2013 2 commits
    • Owen W. Taylor's avatar
      GdkDisplay: handle multiple calls to _gdk_display_pause_events() · e4aa9f05
      Owen W. Taylor authored
      Since events can be paused independently for each window during processing,
      make _gdk_display_pause_events() count how many times it is called
      and only unpause when unpause_events() is called the same number of
      times.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=685460
      e4aa9f05
    • Owen W. Taylor's avatar
      Compress motion synchronized with the paint cycle · a69285da
      Owen W. Taylor authored
      When we have pending motion events, instead of delivering them
      directly, request the new FLUSH_EVENTS phase of the frame clock.
      This allows us to compress repeated motion events sent to the
      same window.
      
      In the FLUSH_EVENTS phase, which occur at priority GDK_PRIORITY_EVENTS + 1,
      we deliver any pending motion events then turn off event delivery
      until the end of the next frame. Turning off event delivery means
      that we'll reliably paint the compressed motion events even if more
      have arrived.
      
      Add a motion-compression test case which demonstrates behavior when
      an application takes too long handle motion events. It is unusable
      without this patch but behaves fine with the patch.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=685460
      a69285da
  19. 03 Apr, 2012 1 commit
  20. 01 Mar, 2012 2 commits
    • Carlos Garnacho's avatar
      gdk: Add internal API to deal with touch implicit grabs · b5cfdf2d
      Carlos Garnacho authored
      The necessary information about a touch implicit grab is stored in
      GdkTouchGrabInfo structs, these are meant to be transient to the
      touch sequence.
      b5cfdf2d
    • Carlos Garnacho's avatar
      gdk: Generate crossing events around touch devices' press/release · 8689921b
      Carlos Garnacho authored
      Anytime a touch device interacts, the crossing events generation
      will change to a touch mode where only events with mode
      GDK_CROSSING_TOUCH_BEGIN/END are handled, and those are sent
      around touch begin/end. Those are virtual as the master
      device may still stay on the window.
      
      Whenever there is a switch of slave device (the user starts
      using another non-touch device), a crossing event with mode
      GDK_CROSSING_DEVICE_SWITCH may generated if needed, and the normal
      crossing event handling is resumed.
      8689921b
  21. 27 Feb, 2012 1 commit
  22. 23 Feb, 2012 1 commit
    • Carlos Garnacho's avatar
      gdk: Keep track of the last slave device used · 5b014bfd
      Carlos Garnacho authored
      This last slave device (stored per master) is used to fill
      in the missing slave device in synthesized crossing events
      that are not directly caused by a device event (ie due to
      configure events or grabs).
      5b014bfd
  23. 10 Jun, 2011 1 commit
  24. 12 Apr, 2011 1 commit
  25. 01 Feb, 2011 3 commits
  26. 03 Jan, 2011 4 commits
  27. 24 Dec, 2010 1 commit
  28. 21 Dec, 2010 3 commits
    • Benjamin Otte's avatar
      gdk: Allow display subclasses to override the type used for windows · af7afbbe
      Benjamin Otte authored
      We want to have different window types for different displays, so we can
      write code like this:
      
        #if GDK_WINDOWING_X11
          if (GDK_IS_X11_WINDOW (window))
            {
              /* do x11 stuff */
            }
          else
        #endif
        #if GDK_WINDOWING_WAYLAND
          if (GDK_IS_WAYLAND_WINDOW (window))
            {
              /* do wayland stuff */
            }
          else
        #endif
            {
              /* do stuff for unsupported system */
          }
      
      This requires different GdkWindow types and we currently don't have
      that, as only the GdkWindowImpl differs. With this method, every backend
      defines a custom type that's just a simple subclass of GdkWindow. This
      way GdkWindow behaves like all the other types (visuals, screens,
      displays) and we can write code like the above.
      af7afbbe
    • Benjamin Otte's avatar
      gdk: Create windows via _gdk_display_create_window() · 3036922b
      Benjamin Otte authored
      THe use of this function will become visible in the next commits. But
      wrapping g_object_new() is a generally a good idea anyway.
      3036922b
    • Matthias Clasen's avatar
      Deal with property encoding functions · 572bb200
      Matthias Clasen authored
      Move everything dealing with compound text to be X11 specific
      Only gdk_text_property_to_utf8_list and gdk_utf8_to_string_target
      are kept across backends, so add vfuncs for these.
      
      Also, remove the non-multihead-safe variants of all these.
      572bb200