[PATCH 3/3] exa/mixed: Exclude frontbuffer from deferred pixmap handling.

[Maarten Maathuis]

2010/12/20 Michel Dänzer <michel at daenzer.net>:
> On Mon, 2010-12-20 at 15:54 +0100, Maarten Maathuis wrote:
>> 2010/12/20 Michel Dänzer <michel at daenzer.net>:
>> > On Mon, 2010-12-20 at 15:46 +0100, Maarten Maathuis wrote:
>> >> 2010/12/14 Michel Dänzer <michel at daenzer.net>:
>> >> > On Mon, 2010-12-13 at 19:42 +0100, Maarten Maathuis wrote:
>> >> >> - Apps like xterm can trigger a lot of fallback rendering.
>> >> >> - This can lead to (annoyingly) high latencies, because you
>> >> >>   have to wait for the block handler.
>> >> >> - You need a driver that doesn't directly access the front
>> >> >>   buffer to trigger this (NV50+ nouveau for example).
>> >> >> - Repeatingly doing dmesg on an xterm with a bitmap font
>> >> >>   will reveal that you never see part of the text.
>> >> >> - I have recieved at least one complaint in the past of slow
>> >> >>   terminal performance, which was related to core font
>> >> >>   rendering.
>> >> >> - This does sacrifice some throughput, not sure how much,
>> >> >
>> >> > Shouldn't be hard to measure.
>> >>
>> >> I did a little test (catting a saved copy of dmesg) and the throughput
>> >> loss is about 25%.
>> >
>> > What are the absolute numbers?
>>
>> Roughly 250 ms vs 330 ms (error margin is about 20-30 ms if i had to guess).
>
> That seems rather inaccurate, can you try something at least an order of
> magnitude bigger?

Forgot about it for a while, but it remains 33% slower, for 10 times
the text. Times are typically 2.7 - 2.8 s vs 3.6 - 3.7 s.

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



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.