Damage as a DIX notion

[Keith Packard]

Michel Dänzer <michel at daenzer.net> writes:

> And it should be relatively easy to get that with the existing damage
> code. Since glamor is only interested in the damage region extents, it
> can set a DamageReportFunc which drops everything but the extents of the
> current operation, something like (based on a function used by the
> amdgpu/radeon drivers):

We're actually thinking of getting rid of the wrappers for damage and
doing them in DIX instead. Reducing the per-operation damage to just a
bounding box would make this a bunch simpler as well -- the pre/post op
damage bits can be handled by doing:

        compute_bounds(&bounds)
        pre_op_damage(&bounds)
        operation(...)
        post_op_damage(&bounds)

In my mail to Eric, I suggest providing DIX-level functions that handle
an entire core operation, much like Render does:

        PolyPoint(DrawablePtr drawable,
        	  GCPtr gc,
                  int npoint,
                  xPoint *points)
        {
            BoxRec bounds
	    if (gc->serialNumber != drawable->serialNumber)
		ValidateGC(drawable, gc);
            bounds_poly_point(drawable, gc, npoint, points, &bounds);
            pre_op_damage(drawble, &bounds);
            (*gc->ops->PolyPoint)(drawable, gc, npoint, points, &bounds);
            post_op_damage(drawable, &bounds);
        }                 

> Based on my experience with the amdgpu/radeon drivers, the CPU overhead
> of this might be acceptable as is.

I think the only operation which might expose the overhead is text, both
core and render.

> (Such a new damageLevel might even be interesting for compositors as
> well)

DamageReportBoundingBox provides something like this.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160925/f33dd636/attachment.sig>