1. 17 Jan, 2017 10 commits
  2. 16 Jan, 2017 6 commits
  3. 15 Jan, 2017 1 commit
  4. 03 Jan, 2017 17 commits
  5. 16 Dec, 2016 1 commit
    • Daniel Stone's avatar
      compositor: Assign new views to the primary plane · fb4869d6
      Daniel Stone authored
      When we create a new view, assign it to the primary plane from the
      beginning.
      
      Currently, every view across the compositor will be assigned to a plane
      during every repaint cycle of every output: the DRM renderer's
      assign_planes hook will either move a view to a drm_plane, or to the
      primary plane if a suitable drm_plane could not be found for the output
      it is on. There are no other assign_planes implementation, and the
      fallback when none is provided, is to assign every view to the primary
      plane.
      
      DRM's behaviour is undesirable in multi-output situations, since it
      means that views which were on a plane on one output will be demoted to
      the primary plane; doing this causes damage, which will cause a spurious
      repaint for the output. This spurious repaint will have no effect on the
      other output, but it will do the same demotion of views to the primary
      plane, which will again provoke a repaint on the other output.
      
      With a simple fix for this behaviour (i.e. not moving views which are
      only visible on other outputs), the following behaviour is observed:
        - outputs A and B are present
        - views A and B are created for those outputs respectively, with SHM
          buffers attached; view->plane == NULL for both
        - current buffer content for views A and B are uploaded to the
          renderer
        - output A runs its repaint cycle, and sets keep_buffer to false on
          surface B's output, as it can never be promoted to a plane; it does
          not move view B to another plane
        - output B runs its repaint cycle, and moves view B to the primary
          plane
        - weston_view_assign_to_plane has work to do (as the plane is changing
          from NULL to the primary plane), calls weston_surface_damage and
          calls weston_surface_damage
        - weston_surface_damage re-uploads buffer content, possibly from
          nowhere at all; e508ce6a notes that this behaviour is broken
      
      Assigning views to the primary plane when created makes it possible to
      fix the DRM assign_planes implementation: assign_planes will always set
      keep_buffer to true if there is any chance the buffer can ever be
      promoted to a plane, regardless of view configruation. If the buffer
      cannot be promoted to a plane, it must by definition never migrate from
      the primary plane. This means that there is no opportunity to hit the
      same issue, where the buffer content has already been discarded, but
      weston_view_assign_to_plane is not a no-op.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
      fb4869d6
  6. 12 Dec, 2016 5 commits