On 27/09/16 01:10 AM, Keith Packard wrote: > 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.
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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
