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

Ferry Huberts mailings at hupie.com
Mon Feb 21 08:30:52 PST 2011



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 <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.
> 

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


More information about the xorg-devel mailing list