[PATCH] exa/mixed: Partially restore deferred pixmap handling for frontbuffer.

[Michel Dänzer]

On Fre, 2011-02-18 at 14:23 +0100, Maarten Maathuis wrote: 
> 2011/2/11 Maarten Maathuis <madman2003 at gmail.com>:
> > 2011/2/11 Michel Dänzer <michel at daenzer.net>:
> >> On Don, 2011-02-10 at 20:44 +0100, Maarten Maathuis wrote:
> >>> 2011/2/10 Michel Dänzer <michel at daenzer.net>:
> >>> > On Don, 2011-02-10 at 20:15 +0100, Maarten Maathuis wrote:
> >>> >> - It turns out that part of the problem was actually on the driver side.
> >>> >> - The performance loss is not worth the small visual improvement.
> >>> >> - This should ensure low latency at low throughput.
> >>> >> - Performance loss seems about 5% instead of the previous 33%.
> >>> >
> >>> > As you've lowered the performance loss number again, I assume you mean
> >>> > 'high throughput' above. :)
> >>>
> >>> I really mean low latency at low throughput (typing for example), [...]
> >>
> >> That was always covered by the BlockHandler. Your problem was only due
> >> to the BlockHandler not getting called for a long time (and/or the
> >> driver not flushing properly in its own BlockHandler).
> >
> > Even before i read this i got the idea if i shouldn't triple check if
> > I'm trying to solve a problem that doesn't exist anymore. So i'll do
> > some more testing. Maybe a revert is even in order. I made a mistake
> > once, i don't want to make a second one on top of that :)
> 
> It seems that the appearance of large amounts of text scrolling over
> the screen depends on how high the throughput is, it seems a bit
> stupid to slow things down for the sake of appearance, plus it's very
> possible other people won't see it like I do due to a slightly faster
> or slower system. I'll probably sent a revert later today or tomorrow.

Well, unless I'm missing something, a client bombing the server with
rendering requests could in theory prevent the BlockHandler from getting
called indefinitely, so if those all ended up being software fallbacks
on the screen pixmap, the visible screen contents would never get
updated. So it might be nice to have some kind of timeout.

That said, I think the same problem should also affect all unaccelerated
drivers using miext/shadow for deferred screen updates, but there
haven't seemed to be any complaints in all these years. So the revert
should be fine for now.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer