1. 23 Jan, 2021 3 commits
    • Olivier Fourdan's avatar
      compositor: Add throttled repaint · 80498847
      Olivier Fourdan authored
      When using vblank while the screen is turned off, only 1 notification
      per second is triggered.
      
      In such a case, there is no need for the compositor to retry repainting
      the screen at such a high pace as when when the screen is on.
      
      To avoid wasting power resources, simply throttle repaints after 100
      unsuccessful retries.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <fourdan@xfce.org>
      Closes:#502
      80498847
    • Olivier Fourdan's avatar
      compositor: Do not clear timeout on retry · cb06a039
      Olivier Fourdan authored
      When using vblank (either GLX or Xpresent), a previous paint request may
      still be pending while new damage notifications are triggered by clients
      updates.
      
      If that occurs, xfwm4 does not cancel the existing timeout previously
      created timeout (so it will retry automatically) but clears the timeout
      id.
      
      As a result, if new damage occurs, a new timeout would be created while
      an existing one is still running.
      
      When using Xpresent while the screen is turned off, no Xpresent event
      notification occur, which increases the risk of the above occuring.
      
      Clear the timeout id only when the repaint succeeded, so we don't pile
      up multiple retries.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <fourdan@xfce.org>
      See-also: #502
      cb06a039
    • Olivier Fourdan's avatar
      compositor: Fix repaint timeout · 88c735c9
      Olivier Fourdan authored
      Commit 2fa246ca ("Add define for compositor_timeout_cb interval")
      replaced g_timeout_add() with g_timeout_add_full() to separate the
      timeout and priority.
      
      Unfortunately, in doing so, it confused the timeout and priority and
      decreased the priority slightly, causing the repaint timeout to occur
      less often, causing delays in repaint.
      
      Fix the priority and timeout as intended.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <fourdan@xfce.org>
      Fixes: 2fa246ca - Add define for compositor_timeout_cb interval
      Closes: #503
      88c735c9
  2. 09 Jan, 2021 2 commits
  3. 05 Jan, 2021 1 commit
  4. 25 Dec, 2020 1 commit
  5. 14 Dec, 2020 4 commits
  6. 12 Dec, 2020 3 commits
  7. 08 Dec, 2020 1 commit
    • Olivier Fourdan's avatar
      Revert "compositor: Do not damage on opaque region update" · 5f66a420
      Olivier Fourdan authored
      Thunderbird is acting really weird with its opaque region, it sometimes
      set a (wrong) opaque region for a very short time during resize and
      immediately remove it, but that can prevent non-opaque regions such as
      drop shadows with client side decorations from being damaged correctly.
      
      While this is clearly a client bug, it shows that damaging the
      difference on opaque region update can be useful.
      
      This reverts commit 1e80481a.
      5f66a420
  8. 07 Dec, 2020 1 commit
  9. 05 Dec, 2020 2 commits
  10. 29 Nov, 2020 1 commit
  11. 28 Nov, 2020 11 commits
  12. 21 Nov, 2020 4 commits
  13. 15 Nov, 2020 2 commits
  14. 14 Nov, 2020 3 commits
  15. 11 Nov, 2020 1 commit
    • Olivier Fourdan's avatar
      compositor: Limit opaque region clipping to window extents · d474e073
      Olivier Fourdan authored
      The opaque region is set and updated by the client, which may lag when
      the window is resized.
      
      That may leave unpainted areas when resizing a window as the opaque
      region set by the client could be actually larger than the window itself
      and hence prevent areas to be updated while they should, causing
      artifacts on screen.
      
      Make sure to limit the clipping of the opaque region by the window
      extents to avoid the issue.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <fourdan@xfce.org>
      d474e073