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