[PATCH] xwayland: Fix damage reporting
Jasper St. Pierre
jstpierre at mecheye.net
Mon Apr 21 11:12:55 PDT 2014
Why do we end up with such a large damage anyway? Technically, we need to
ignore this in mutter, as it's perfectly valid to have a too-big damage.
Rather than do the clip in Xwayland, I'd like to figure out why damage
reporting for a window we know the bounds of is so unrealistically large,
because this could be a bug hitting us on Xorg as well.
On Sat, Apr 19, 2014 at 4:26 AM, Adel Gadllah <adel.gadllah at gmail.com>wrote:
> Currently we accumulate damage in a list and call wl_surface_damage() for
> every
> rectangle in the accumulated regions in xwl_screen_post_damage(). If the
> window
> size changes we might end up with a damage region that exceeds the window
> bounds causing compositors like mutter to call glTexSubImage2D with an area
> that exceeds the buffer dimensions causing GL_INVALID_VALUE.
>
> So intersect the damage region with the window's shape region in
> xwl_screen_post_damage().
>
> Signed-off-by: Adel Gadllah <adel.gadllah at gmail.com>
> ---
> hw/xwayland/xwayland.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index c2c6481..7f810aa 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -325,7 +325,7 @@ static void
> xwl_screen_post_damage(struct xwl_screen *xwl_screen)
> {
> struct xwl_window *xwl_window;
> - RegionPtr region;
> + RegionPtr region, shape_region;
> BoxPtr box;
> int count, i;
> struct wl_buffer *buffer;
> @@ -334,6 +334,9 @@ xwl_screen_post_damage(struct xwl_screen *xwl_screen)
> xorg_list_for_each_entry(xwl_window, &xwl_screen->damage_window_list,
> link_damage) {
> region = DamageRegion(xwl_window->damage);
> + shape_region = wBoundingShape(xwl_window->window);
> + if (shape_region)
> + RegionIntersect(region, region, shape_region);
> count = RegionNumRects(region);
>
> pixmap = (*xwl_screen->screen->GetWindowPixmap)
> (xwl_window->window);
> --
> 1.9.0
>
>
--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140421/a9cb5397/attachment.html>
More information about the xorg-devel
mailing list