Damage as a DIX notion

[Keith Packard]

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.

> 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. And, as much of
that code is in the core server now, we shouldn't see huge impacts on
the drivers?

-- 
-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/20160926/b17688a2/attachment.sig>