Damage as a DIX notion

[Michel Dänzer]

On 27/09/16 01:10 AM, Keith Packard wrote:
> Eric Anholt <eric at anholt.net> writes:
> 
>> You're also going to be doing extra rendering as a result of tearfree,
>> right?  (I assume this is double or triple buffering and back-copying
>> damage).  If that's the hit for dots just from damage computation, then
>> I think we need to go the keithp proposed API route (or do the quick
>> hack of "hey, look, 100000 dots on my 100x100 window, I'll just say the
>> whole thing is damaged).
> 
> Yeah, at least doing a mixed model where operations which are dominated
> by overhead (dots and glyphs) get a different API than operations which
> are dominated by rendering.

My numbers showed about 25% overhead for dots, 5% for glyphs. That's not
exactly "dominating".


>> I'm really hesitant to rely on the current damage reports for bounds of
>> my rendering.  It feels very fragile for situations where you have an
>> operation decompose into multiple operations in one of your layers (like
>> Trapezoids, which have a fill then addtraps then a composite).  We
>> certainly fought with this in EXA, and it's why I'd like to have an
>> explicit damage computation available for the args given in an op.
> 
> I think the key is that we just don't have that much rendering code that
> would need fixing, so if we have to go touch every single function to
> change the arguments, now seems like a pretty good time.

I'd say it's about a decade late, seeing as the major distros are about
to switch to Wayland/Mir by default.


> And, as much of that code is in the core server now, we shouldn't see
> huge impacts on the drivers?

I wish. Our drivers have wrappers for all rendering hooks. Please don't
force gratuitous churn on them.


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