1. 12 Jun, 2014 1 commit
    • Matthias Clasen's avatar
      Drop GDK_MULTIHEAD_SAFE · 5334fb89
      Matthias Clasen authored
      We don't support multiple screens anymore, so there is no need
      for marking API as multihead safe any longer.
      5334fb89
  2. 23 May, 2014 1 commit
  3. 19 May, 2014 1 commit
  4. 13 May, 2014 1 commit
    • Jasper St. Pierre's avatar
      gdk: Add new _gdk_set_window_state · c1efc4ad
      Jasper St. Pierre authored
      Wayland's mechanism tells us all of our new states, rather than
      telling us which ones were added and removed. Add a new private
      interface so that we can simply specify the new states as a
      bitfield directly rather than having to compute which ones were
      added and removed.
      c1efc4ad
  5. 11 May, 2014 1 commit
  6. 19 Feb, 2014 1 commit
  7. 15 Feb, 2014 1 commit
  8. 07 Feb, 2014 3 commits
  9. 05 Feb, 2014 1 commit
  10. 04 Feb, 2014 2 commits
  11. 29 Jan, 2014 1 commit
  12. 28 Jan, 2014 1 commit
  13. 21 Jan, 2014 1 commit
  14. 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
  15. 11 Nov, 2013 1 commit
  16. 09 Nov, 2013 1 commit
  17. 11 Oct, 2013 1 commit
  18. 10 Sep, 2013 1 commit
  19. 13 Aug, 2013 1 commit
  20. 14 Feb, 2013 3 commits
    • Owen W. Taylor's avatar
      Don't compress motion events for different devices · e2705544
      Owen W. Taylor authored
      A switch of device may be significant for an application, so don't
      compress motion events if they are for different devices. This simple
      handling isn't sufficient if we have competing event streams from
      two different pointer events, but we don't expect this case to be
      common.
      e2705544
    • 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
  21. 10 Jun, 2012 1 commit
  22. 13 Apr, 2012 1 commit
  23. 01 Mar, 2012 5 commits
  24. 27 Feb, 2012 1 commit
  25. 27 Jan, 2012 1 commit
  26. 17 Nov, 2011 1 commit
  27. 27 Sep, 2011 1 commit
  28. 28 Aug, 2011 1 commit
  29. 09 Apr, 2011 1 commit
  30. 25 Feb, 2011 1 commit
  31. 17 Feb, 2011 1 commit