Re: Damage as a DIX notion

On 27/09/16 01:10 AM, Keith Packard wrote: > Eric Anholt 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

Re: Damage as a DIX notion

On 27/09/16 12:40 AM, Eric Anholt wrote: > Michel Dänzer writes: >> On 26/09/16 11:23 AM, Keith Packard wrote: >>> Eric Anholt writes: >>> In talking with ajax, I came around to "just compute the bounds up front, always." >>> >>> That's certainly

Re: Damage as a DIX notion

On 2016-09-26 5:34 AM, Michel Dänzer wrote: > On 26/09/16 11:23 AM, Keith Packard wrote: >> A data-driven approach would be awesome here. Do we have a reasonable >> performance metric? I'm no fan of gratuitous complexity, but text >> performance is pretty important to me. > > Here are some data

Re: Damage as a DIX notion

Eric Anholt 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

Re: Damage as a DIX notion

Michel Dänzer writes: > On 26/09/16 11:23 AM, Keith Packard wrote: >> Eric Anholt writes: >> >>> In talking with ajax, I came around to "just compute the bounds up >>> front, always." >> >> That's certainly simpler. It would be useful to go and measure how

Re: Damage as a DIX notion

Michel Dänzer writes: > Right, but I'm questioning if any gains from that vs using and possibly > tweaking the current damage code (what would the expected gains be?) are > enough to justify the churn. The current stack has gotten pretty unwieldy in the normal case, being

Re: Damage as a DIX notion

On 26/09/16 12:01 PM, Keith Packard wrote: > Michel Dänzer writes: > >> And it should be relatively easy to get that with the existing damage >> code. Since glamor is only interested in the damage region extents, it >> can set a DamageReportFunc which drops everything but the

Re: Damage as a DIX notion

On 26/09/16 11:23 AM, Keith Packard wrote: > Eric Anholt writes: > >> In talking with ajax, I came around to "just compute the bounds up >> front, always." > > That's certainly simpler. It would be useful to go and measure how much > of firefox's (and maybe other applications?)

Re: Damage as a DIX notion

Michel Dänzer writes: > And it should be relatively easy to get that with the existing damage > code. Since glamor is only interested in the damage region extents, it > can set a DamageReportFunc which drops everything but the extents of the > current operation, something

Re: Damage as a DIX notion

Eric Anholt writes: > In talking with ajax, I came around to "just compute the bounds up > front, always." That's certainly simpler. It would be useful to go and measure how much of firefox's (and maybe other applications?) rendering is aimed at pixmaps without damage tracking

Re: Damage as a DIX notion

On 26/09/16 05:45 AM, Eric Anholt wrote: > > In talking with ajax, I came around to "just compute the bounds up > front, always." And it should be relatively easy to get that with the existing damage code. Since glamor is only interested in the damage region extents, it can set a

Re: Damage as a DIX notion

Keith Packard writes: > Adam, Eric and I were chatting at XDC about how to make damage > computations more efficient and more useful. > > The impetus of this was that glamor on tilers would like to have the > bounds of every operation to reduce the number of tiles processed

Damage as a DIX notion

Adam, Eric and I were chatting at XDC about how to make damage computations more efficient and more useful. The impetus of this was that glamor on tilers would like to have the bounds of every operation to reduce the number of tiles processed for small operations. Damage already computes the