Re: [PATCH xserver 02/10 v2] glamor: Require that 16bpp pixmap depths match for Render copies.

2016-09-26 Thread Michel Dänzer
On 26/09/16 03:53 AM, Eric Anholt wrote: > Michel Dänzer writes: >> On 23/09/16 09:51 PM, Eric Anholt wrote: >>> >>> We do need some concerted effort on actually fixing our rendering bugs >>> and reenabling the skipped tests. I've spent a while trying to come up >>> with why the remaining renderc

Re: Damage as a DIX notion

2016-09-26 Thread Michel Dänzer
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 computation, then >> I thi

Re: Damage as a DIX notion

2016-09-26 Thread Michel Dänzer
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 simpler. It would be useful to go and me

Re: Damage as a DIX notion

2016-09-26 Thread Peter Harris
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 po

Correction

2016-09-26 Thread Mihail Konev
> Make sure device removes are processed before doing a VT switch, > so that no removes are "overwritten" with attachments afterwards > (before the main thread releases the input lock, letting them be > processed), which would leave affected devices disabled. The dev->state is not "overwritten wit

Re: Damage as a DIX notion

2016-09-26 Thread Keith Packard
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 proposed API route (or

Re: Damage as a DIX notion

2016-09-26 Thread Eric Anholt
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 much >> of firefox's (and maybe other

Re: Damage as a DIX notion

2016-09-26 Thread Keith Packard
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 largely unchanged since

Re: Damage as a DIX notion

2016-09-26 Thread Michel Dänzer
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 extents of the >> cu

Re: Damage as a DIX notion

2016-09-26 Thread Michel Dänzer
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?) rendering is aime