Clarifying the Damage extension (Re: AIGLX on Radeon Mobility)

[Owen Taylor]

On Sat, 2006-02-25 at 16:45 +0100, Keith Packard wrote:
> On Fri, 2006-02-24 at 16:24 -0500, Adam Jackson wrote:
> 
> > I don't find it so much hard to understand as just plain _wrong_.  I think 
> > there's a mistake being made here in trying to do both internal reporting - 
> > for shadow, sw cursor, automatic compositing, etc. - and external reporting 
> > using the same mechanism.  It feels like damageext/ shouldn't be implemented 
> > in terms of miext/damage.
> 
> The implementation cost is all about converting rendering requests into
> appropriate bounding rectangles, so having only one copy of that code
> seems important.
> 
> The execution cost is all about hitting only one such conversion, so we
> want to share that at run time as well.
> 
> This means that (at least for regular client rendering), we really want
> to use the same layer.
> 
> I think that means we just need to finish suitable hacks so that
> 'internal' drawing avoid causing damage for 'external' clients.
> 
> The most critical thing right now is to write down a comprehensive
> specification for what 'damage' means, then write test cases to make it
> happen.

To at least get some prior work in the area out on the table, I'm
attaching here:

 - A revision to the DamageExt protocol spec that I came up with
   just about a year ago.
 - A long IRC conversation with Keith as background to that
   revision. (The first part of it is before I came up with the
   patch; the resumption is discussing the patch.) 

The revision to the spec has a couple of goals:

 - To provided a precise definition of what Damage is; this is
   is done by introducing the concept of 'known region' of a
   drawable and defining Damage as the combination of changes
   to the known region and changes to pixel contents within 
   the known region.

 - To nail down how Damage interacts with Composite. This patch
   actually makes the Damage specification depend upon Composite,
   since trying to specify the interaction in abstract terms
   without reference to Composite would result in a vastly
   more confusing and imprecise result.

 - To provide at least some guidance as to how Damage might
   interact with multi-depth displays. The core protocol leaves
   them pretty undefined, I've tried to simply refer to that
   undefinition by defining the known region in terms of the
   behavior of CopyArea.

 - To add examples to clarify the rules

I don't think that Keith had any real objections to the ideas
in this revision, but the utility of the revision without a test 
cases is pretty much zero. Writing the test cases would
doubtless also show that my attempts to be precise have gaping
holes in them.

Regards,
					Owen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: DamageExt.patch
Type: text/x-patch
Size: 9519 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060225/fcabca1e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DamageExt-keithp-otaylor-irc.log
Type: text/x-log
Size: 34409 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060225/fcabca1e/attachment-0001.bin>