2011/1/18 Michel Dänzer <[email protected]>: > On Mon, 2011-01-17 at 21:45 +0100, Maarten Maathuis wrote: >> 2010/12/20 Michel Dänzer <[email protected]>: >> > On Mon, 2010-12-20 at 15:54 +0100, Maarten Maathuis wrote: >> >> 2010/12/20 Michel Dänzer <[email protected]>: >> >> > On Mon, 2010-12-20 at 15:46 +0100, Maarten Maathuis wrote: >> >> >> 2010/12/14 Michel Dänzer <[email protected]>: >> >> >> > 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. > > Okay, thanks. I guess this might be acceptable for a substantial > decrease in latency, but I can't help wondering if we couldn't get that > with less if any sacrifice in throughput. Have you tried or thought > about anything else? Some random ideas offhand: > > * Limit the amount of deferred dirtiness, be it wall clock based > or even just a simple counter of deferred ops. > * Flushing the deferred dirtiness in other places in addition to > (or instead of) the BlockHandler, e.g. a flush callback. >
I kind of went for the "best" solution in terms of latency (considering it doesn't happen all that often for most people), the second best would probably be a frontbuffer area counter, requiring a certain square pixel damaged area before flushing. The downside is that latency while typing in a console will still be there. Some kind of maximum latency timer might work as well, although i don't know if the xserver has those. But that won't reduce latency to a minimum in low throughput situations. > > -- > 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
