From: Pekka Paalanen <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
