1. 02 Sep, 2019 12 commits
    • Jonas Ådahl's avatar
      x11: Trace XEvent processing · 3c0067dc
      Jonas Ådahl authored and Georges Basile Stavracas Neto's avatar Georges Basile Stavracas Neto committed
    • Jonas Ådahl's avatar
      wayland: Trace wl_surface.commit · a957c2f0
      Jonas Ådahl authored and Georges Basile Stavracas Neto's avatar Georges Basile Stavracas Neto committed
    • Jonas Ådahl's avatar
    • Olivier Fourdan's avatar
      clutter/input-pointer-a11y: Restore pointer a11y on resume · 2f072af0
      Olivier Fourdan authored and Jonas Ådahl's avatar Jonas Ådahl committed
      When suspending, the devices are removed and the virtual device
      associated with the corresponding core pointer is disposed.
      Add the pointer accessibility virtual device to the core pointer
      on resume to restore pointer accessibility on resume if enabled.
    • Olivier Fourdan's avatar
      wayland/data-device: Restore keyboard focus on drag end · de98fb29
      Olivier Fourdan authored and Jonas Ådahl's avatar Jonas Ådahl committed
      When starting a DnD operation, mutter would remove keyboard focus from
      the client, only to restore it on the data offer destroy.
      However, if the DnD fail, the keyboard focus is not restored, leaving
      the user unable to type in the focused window, even after clicking in
      the window.
      That issue would show only on first attempt, as further DnD attempts
      would destroy the previous data offer which would also restore the
      keyboard focus.
      Make sure we restore the keyboard focus on drag end as well.
    • Olivier Fourdan's avatar
      wayland/data-device: Do not unset focus on drag start · 82c92177
      Olivier Fourdan authored and Jonas Ådahl's avatar Jonas Ådahl committed
      On drag start, `data_device_start_drag()` issues a keyboard grab, which
      in turn will unset the current input focus.
      There is not need to unset the input focus in `data_device_start_drag()`
      as this is redone in `meta_wayland_keyboard_start_grab()`
    • Daniel van Vugt's avatar
      clutter: Introduce geometric picking · 14c706e5
      Daniel van Vugt authored and Jonas Ådahl's avatar Jonas Ådahl committed
      Currently, Clutter does picking by drawing with Cogl and reading
      the pixel that's beneath the given point. Since Cogl has a journal
      that records drawing operations, and has optimizations to read a
      single pixel from a list of rectangle, it would be expected that
      we would hit this fast path and not flush the journal while picking.
      However, that's not the case: dithering, clipping with scissors, etc,
      can all flush the journal, issuing commands to the GPU and making
      picking slow. On NVidia-based systems, this glReadPixels() call is
      extremely costly.
      Introduce geometric picking, and avoid using the Cogl journal entirely.
      Do this by introducing a stack of actors in ClutterStage. This stack
      is cached, but for now, don't use the cache as much as possible.
      The picking routines are still tied to painting.
      When projecting the actor vertexes, do it manually and take the modelview
      matrix of the framebuffer into account as well.
      CPU usage on an Intel i7-7700, tested with two different GPUs/drivers:
        |         |     Intel | Nvidia |
        | ------: | --------: | -----: |
        | Moving the mouse:            |
        | Before  |       10% |    10% |
        | After   |        6% |     6% |
        | Moving a window:             |
        | Before  |       23% |    81% |
        | After   |       19% |    40% |
      Closes: GNOME/mutter#154,
      Helps significantly with: GNOME/mutter#283,
      v2: Fix code style issues
          Simplify quadrilateral checks
          Remove the 0.5f hack
          Differentiate axis-aligned rectangles
    • Daniel van Vugt's avatar
      clutter/point: Add ClutterPoint quarilateral testing API · a70823dd
      Daniel van Vugt authored and Jonas Ådahl's avatar Jonas Ådahl committed
      Add a function to check whether a point is inside a quadrilateral
      by checking the cross product of vectors with the quadrilateral
      points, and the point being checked.
      If the passed quadrilateral is zero-sized, no point is ever reported
      to be inside it.
      This will be used by the next commit when comparing the transformed
      actor vertices.
      [feaneron: add a commit message and remove unecessary code]
    • Rémi Bernon's avatar
    • Rémi Bernon's avatar
      core: Fix multiple reparent requests handling · 8f242f8b
      Rémi Bernon authored
      If window decoration is modified within a short period of time, mutter
      sometimes starts processing the second request before the first
      UnmapNotify event has been received. In this situation, it considers
      that the window is not mapped and does not expect another UnmapNotify /
      MapNotify event sequence to happen.
      This adds a separate counter to keep track of the pending reparents. The
      input focus is then restored when MapNotify event is received iff all
      the expected pending ReparentNotify events have been received.
      Signed-off-by: Rémi Bernon's avatarRémi Bernon <rbernon@codeweavers.com>
    • Mart Raudsepp's avatar
      build: Raise libXi minimum dependency for required deadlock fixes · 36a14e65
      Mart Raudsepp authored and Jonas Ådahl's avatar Jonas Ådahl committed
      Older than 1.7.4 have deadlock bugs, see
    • Daniel van Vugt's avatar
      cogl: Remove GLX "threaded swap wait" used on Nvidia · 6ed5d2e2
      Daniel van Vugt authored
      Threaded swap wait was added for using together with the Nvidia GLX
      driver due to the lack of anything equivalent to the INTEL_swap_event
      GLX extension. The purpose was to avoid inhibiting the invocation of
      idle callbacks when constantly rendering, as the combination of
      throttling on swap-interval 1 and glxSwapBuffers() and the frame clock
      source having higher priority than the default idle callback sources
      meant they would never be invoked.
      This was solved in gbz#779039 by introducing a thread that took care of
      the vsync waiting, pushing frame completion events to the main thread
      meaning the main thread could go idle while waiting to draw the next
      frame instead of blocking on glxSwapBuffers().
      As of GNOME/mutter!363, the
      main thread will instead use prediction to estimate when the next frame
      should be drawn. A side effect of this is that even without
      INTEL_swap_event, we would not block as much, or at all, on
      glxSwapBuffers(), as at the time it is called, we have likely already
      hit the vblank, or will hit it soon.
      After having introduced the swap waiting thread, it was observed that
      the Nvidia driver used a considerable amount of CPU waiting for the
      vblank, effectively wasting CPU time. The need to call glFinish() was
      also problematic as it would wait for the frame to finish, before
      continuing. Due to this, remove the threaded swap wait, and rely only on
      the frame clock not scheduling frames too early.
      Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=781835
      Related: GNOME/mutter#700
      [jadahl: Rewrote commit message]
  2. 31 Aug, 2019 3 commits
  3. 29 Aug, 2019 1 commit
  4. 28 Aug, 2019 1 commit
  5. 27 Aug, 2019 15 commits
  6. 26 Aug, 2019 7 commits
  7. 25 Aug, 2019 1 commit