[PATCH xserver 4/4] damage: Make damageRegionProcessPending take a damage not a drawable

[Michel Dänzer]

On 30.04.2016 03:22, Adam Jackson wrote:
> In the case where there's no damage monitor on the drawable, we look
> that fact up twice: once before rendering to decide whether to compute
> damage, and again after to decide whether to append it. This is wasted
> effort, as the layer below us is effectively not allowed to change
> whether there's a damage monitor for the drawable, but there's no way
> the compiler can know that.
> 
> Instead, look it up once up front, and change the check macros and
> damageRegionProcessPending to refer to it.
> 
> Signed-off-by: Adam Jackson <ajax at redhat.com>

[...]

> @@ -457,7 +456,7 @@ damageDestroyClip(GCPtr pGC)
>  #define BOX_NOT_EMPTY(box) \
>      (((box.x2 - box.x1) > 0) && ((box.y2 - box.y1) > 0))
>  
> -#define checkGCDamage(d,g)	(getDrawableDamage(d) && \
> +#define checkGCDamage(d,g)	(pDamage && \
>  				 (!g->pCompositeClip ||\
>  				  RegionNotEmpty(g->pCompositeClip)))
>  
> @@ -469,8 +468,7 @@ damageDestroyClip(GCPtr pGC)
>      if(box.y2 > extents->y2) box.y2 = extents->y2; \
>      }
>  
> -#define checkPictureDamage(p)	(getDrawableDamage(p->pDrawable) && \
> -				 RegionNotEmpty(p->pCompositeClip))
> +#define checkPictureDamage(p)	(pDamage && RegionNotEmpty(p->pCompositeClip))

These macros now implicitly use pDamage, and checkGCDamage doesn't use
its first parameter anymore. How messy would it be to clean up that
ugliness? At least the removal of checkGCDamage's first parameter could
be done in a separate followup patch.


Apart from that, this patch makes a lot of sense to me.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer