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