On 02/21/2011 01:11 PM, Michel D�nzer wrote: > On Fre, 2011-02-18 at 14:23 +0100, Maarten Maathuis wrote: >> 2011/2/11 Maarten Maathuis <madman2...@gmail.com>: >>> 2011/2/11 Michel Dänzer <mic...@daenzer.net>: >>>> On Don, 2011-02-10 at 20:44 +0100, Maarten Maathuis wrote: >>>>> 2011/2/10 Michel Dänzer <mic...@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. >
How about doing something simple like 'as soon as there are outstanding rendering requests, start a single shot timer, and once it triggers (like after a second), call the BlockHandler if there are still outstanding rendering requests. If after the BlockHandler completes there are still outstanding/new rending requests: repeat this procedure'. that would guarantee a screen update at least once a second when the server is overloaded with rendering requests. grtz -- Ferry Huberts _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel