On Die, 2011-01-18 at 23:59 +0100, Maarten Maathuis wrote: > 2011/1/18 Maarten Maathuis <[email protected]>: > > 2011/1/18 Maarten Maathuis <[email protected]>: > >> 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. > > > > Another idea would be to use a rate limit. It gives you the low > > throughput low latency situation, but still gives decent behaviour at > > higher throughput. Just need to think of the right timer to use and > > what maximum rate to use. > > The rate limiting quickly converges to the "new" times, while still > giving the impression of missing text. So the question is, should the > user get what he/she expects (namely line by line drawing of text > instead of the quasi random blocks appearing on screen) or do we > compromise on just reducing latency for low throughput cases like > typing in a terminal or relatively short multi line output?
Please show us what exactly you have tried. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
