[RFC xserver 0/1] Xwayland to send more accurate damage

[Pekka Paalanen]

From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>

Hi,

currently Xwayland collapses all wl_surface damage into a single bounding
rectangle. If the actual damage area is just a fraction of the sent damage
area, this will cause massive extra work in the Wayland compositor. The effect
is most notable in software rendered Wayland compositors. However, I would not
be surprised if there were measurable benefits for GPU accelerated Wayland
compositors, particularly if Xwayland was still software rendered but also with
GLAMOR, on low-end systems and large screens.

The motivation for this RFC is a real world use case with Weston/pixman as the
compositor and a proprietary X11 application in fullscreen. An equivalent patch
was measured to reduce Weston's CPU usage down to one third or one quarter
compared to without the patch. In steady state animation that was roughly from
0.3-0.4 CPUs down to 0.1 CPUs consumed by Weston which was a quite significant
portion of the total CPU power available.

The case was originally discussed on June 28, 2017, on #xorg-devel, but I
couldn't work much on it then.

The patch here is crude: send up to 500 rectangles of accurate damage but if
more, fall back to sending the bounding box. The reason to limit the number of
rectangles is that if the Wayland connection overflows, it will abort Xwayland.

Sending (more) accurate damage increases the risk of Xwayland aborting, so
limiting the number of rectangles is not just a performance question. However,
solving the overflow problem is not the goal here - I just try to mitigate the
risk.

The approach in the patch is problematic, because it uses a single hard-coded
threshold without much justification: the threshold was found by experimenting
with a proprietary application, and if I recall right, 300 was a sufficient
limit while 150 was not, so it was not a case of just a few rectangles in the
damage region.

An idea by ajax was to compute the ratio of accurate damage area vs. the
boundingbox area and use that percentage as a fixed threshold. The idea is nice
and simple, but I think it also needs a limit on the number of rectangles to
reduce the overflow risk.

I have been thinking about an optimization based approach, where one would
essentially assign relative costs to each pixel of extra damage added and each
rectangle sent and attempt to minimize the total cost by merging rectangles
into bigger rectangles before sending.

The questions:

- Which of the three approaches or something else would be sufficient for
  upstream?

- What testing should I perform since sending significantly more Wayland
  requests is risky?

- What X11 applications would be good to analyze for the drawing (damage) they
  produce?

If we need anything more complicated than what is in this patch, then I would
probably like to record the damage regions from various apps to gather a data
set to develop on. Unless you think it's not necessary?


Thanks,
pq

ps. I'll be on holidays until Jan 11, so might not reply until then.

Pekka Paalanen (1):
  xwayland: reduce over-damage

 hw/xwayland/xwayland.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

-- 
2.13.6