From owner-freebsd-current@freebsd.org Thu Jun 30 14:23:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77440B869F9 for ; Thu, 30 Jun 2016 14:23:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CBBC2C27 for ; Thu, 30 Jun 2016 14:23:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x22c.google.com with SMTP id h190so72158042ith.1 for ; Thu, 30 Jun 2016 07:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AZs7lFAMczoFsqK7YZh/q5RitbZ8XzzwfaS6A0Ct/K8=; b=MFQQd9wpTqXmlJIaKcX5swGT4ZB/QeeBvxShrNuBYC4U75J3Um8DUy9mLIszn5D3Eh 1dtkz8HSxT6/9oJPTJtdLbgqM/yOrq4fJU+gUo/NSWnHs/yuwM84P4u3Vplo/MTnFgYy +MZxbX9IN7PhDdXDWdWD3qcB7ZB542oqdhBC1bmkUCsiV0XP3Q4MWib711nyabhclz3Z bdhgYcBJF/Y/6/GvIL8SI5vnl6WZMmPYkkzzgUCXCnLoZmAtkjdgEvwgX9Wygt62LtQP RfTsIdzo5lGKTRl2/kZgj8tG8wuZ48XIfE0QA9ffzKidTu6z3fyWSYqvXDRkEvmXP+LJ MpqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AZs7lFAMczoFsqK7YZh/q5RitbZ8XzzwfaS6A0Ct/K8=; b=gZwNq76sEkE2uzJGO5Ii1wYLzsbWGEB3h0/d9OwOBk/j4jLTsaxe7WHYTxOKIkvlao 4ITDsQBkJFGT3plrRgtWpvCcdI4i/QmCByemJpdxvyBD7VDos2I465YGMD/wZVjsdoVT KrbdI+4Lzfbj5Uhv2gcz54O8hPMD1naN8TRGHoLBT4R/OrCbxEvYBZjpt0HtiS4S8JT9 vqPMZ8gkuNhMg5UnYIi/p3f8i/nm04HxmqX8qoxFJX20i6P2cMu7KnUAweeBgAt1knvm u+dZus/LmdVfX21HcUfwo87uHVllSd/n32d6MEUgkgoGCE+6jcmcg2EB/BsQ16C9uxkq 1xfg== X-Gm-Message-State: ALyK8tL4hRyZcgHL8Qwo5RBunvlB5j3xjdJpVGGlT8W3Ln2oqugcBfJtWMqBWWU6/F5koXMrSwtf7f//JFj0wU+K X-Received: by 10.36.123.75 with SMTP id q72mr24876958itc.44.1467296619644; Thu, 30 Jun 2016 07:23:39 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.125.197 with HTTP; Thu, 30 Jun 2016 07:23:38 -0700 (PDT) In-Reply-To: References: <57680D69.7030309@gmail.com> <20160622090149.GD19494@home.opsec.eu> <576A74D0.2020704@gmail.com> From: Maxim Sobolev Date: Thu, 30 Jun 2016 07:23:38 -0700 X-Google-Sender-Auth: tpGJaXtQQM2WlUDIZBwvJU-NGZE Message-ID: Subject: Re: console in 11.0-ALPHA4 To: Ed Schouten Cc: Ernie Luzar , Kurt Jaeger , =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:23:40 -0000 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 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. > > -Max > > On Thu, Jun 30, 2016 at 6:42 AM, Ed Schouten wrote: > >> Hi Maxim, >> >> 2016-06-28 21:14 GMT+02:00 Maxim Sobolev : >> > 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 >> my >> > 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 >> Nuxi, 's-Hertogenbosch, the Netherlands >> KvK-nr.: 62051717 >> >> >