P.S. Asynchronous nature of vt is also a poor excuse in my view. There are
plenty ways to do it asynchronously, while preserving updates order. It
should not be one-or-the-other deal.
On Thu, Jun 30, 2016 at 7:21 AM, Maxim Sobolev <sobo...@freebsd.org> wrote:
> Ed, I think this is bug, not a feature. People expect scrolling and
> updates to be smooth these days, the fact that we deliberately break it
> just signifies very weird preferences somebody made while developing the
> code. The fact that it "looks fine when scrolling stops" is no execuse IMHO.
> On Thu, Jun 30, 2016 at 6:42 AM, Ed Schouten <e...@nuxi.nl> wrote:
>> Hi Maxim,
>> 2016-06-28 21:14 GMT+02:00 Maxim Sobolev <sobo...@freebsd.org>:
>> > P.S. Just if somebody is interested in fixing those "fast scrolling text
>> > turns into garbage" display issues, here is some screenshots of one of
>> > 11-alpha3 systems captured with a camera at 120fps. As you can see text
>> > tears down quite badly.
>> What happens is that rendering of vt(4) is done asynchronously. In
>> addition to the screen contents, vt(4) keeps track of a rectangular
>> area of the screen that needs to be updated. During every refresh, the
>> rendering thread extracts and resets the coordinates of the
>> rectangular area and redraws that area. It only holds a lock while
>> extracting the rectangle's coordinates; not when redrawing.
>> This means that if you have a lot of updates and redrawing is slow,
>> you will get 'random' garbage on screen. Once output stops, the screen
>> contents get refreshed one final time, making everything look all
>> right again.
>> Ed Schouten <e...@nuxi.nl>
>> Nuxi, 's-Hertogenbosch, the Netherlands
>> KvK-nr.: 62051717
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"