1. 14 May, 2010 3 commits
  2. 15 Apr, 2010 3 commits
  3. 04 Apr, 2010 11 commits
  4. 19 Feb, 2010 1 commit
  5. 20 Jan, 2010 1 commit
  6. 19 Jan, 2010 3 commits
    • Alexander Larsson's avatar
      Drop outstanding cairo surfaces when window is made native · e31a6d1f
      Alexander Larsson authored
      Any old cairo_surface referencing the old impl window will be wrong
      when we make a window native, so drop it.
      
      This fixes bug #599511
      e31a6d1f
    • Alexander Larsson's avatar
      Move common gdkwindow.c code into function gdk_window_drop_cairo_surface · 46d25437
      Alexander Larsson authored
      This code is duplicated in several places, and more to come, so put
      it all in one place.
      46d25437
    • Alexander Larsson's avatar
      Track direct window cairo access and avoid tricks when used · 841fa477
      Alexander Larsson authored
      When a cairo surface is requested for direct window access (i.e. not
      when double-buffering) we can't really track when the actual drawing happens
      as cairo drawing is not virtualized. This means we can't properly flush
      any outstanding window moves or implicit paints.
      
      This actually causes problems with e.g. abiword (bug #606009) where they
      draw without double-buffering. If you press down it scrolls the window
      and then draws the caret, but the caret drawing does not flush the
      outstanding move from the scroll, so the caret gets drawn on the wrong
      screen.
      
      We fix this by never allowing either implicit paints or outstanding window
      moves on impl-windows where any windows related to it has an outstanding
      direct cairo surface. Luckily this is not very common so in practice this
      doesn't matter much.
      841fa477
  7. 15 Jan, 2010 1 commit
  8. 03 Jan, 2010 1 commit
  9. 21 Dec, 2009 1 commit
  10. 18 Dec, 2009 2 commits
  11. 16 Dec, 2009 1 commit
  12. 08 Dec, 2009 3 commits
  13. 02 Dec, 2009 1 commit
    • Alexander Larsson's avatar
      Don't filter out BUTTON_MOTION event masks · b509f285
      Alexander Larsson authored
      We don't really need to filter these out, it was just a leftover
      safety check to not override the GDK_POINTER_MOTION_MASK.
      
      Furthermore when we changed behaviour to not always select for native
      pointer motion it is actually wrong. We'll still get normal motion
      events for the toplevel which we will emulate as button motion on the
      child, but the button motion mask will not be inherited by implicit
      grabs which makes us not get any motion events during grabs.
      
      This fixes bug 601473
      b509f285
  14. 05 Nov, 2009 5 commits
  15. 20 Oct, 2009 1 commit
  16. 05 Oct, 2009 1 commit
  17. 30 Sep, 2009 1 commit