From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Future of display engine and lines Date: Thu, 28 Oct 2021 16:19:44 +0300 Message-ID: <835yththfz.fsf@gnu.org> References: <2108181.AU8Z245p1N@galex-713.eu> <871r4fhxtd.fsf@gnus.org> <83r1cc5i8p.fsf@gnu.org> <834k952tti.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37441"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, galex-713@galex-713.eu, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 28 15:21:43 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mg5Li-0009U6-Cn for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Oct 2021 15:21:42 +0200 Original-Received: from localhost ([::1]:50304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mg5Lg-0006k6-Ho for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Oct 2021 09:21:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg5K8-0005xl-Hf for emacs-devel@gnu.org; Thu, 28 Oct 2021 09:20:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48462) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg5K7-0007nj-Dq; Thu, 28 Oct 2021 09:20:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=XvZIs55pTWuHm3yJc87cU0dzDK4No9IGCrpObFWqDeo=; b=IBFeUZYILeIG zw7Ti6Zp4d8QcxPLr59Zyly4UFkS7WohcyPzb/nxY+Q67a2rJyZ6R0lEhf++cexrFa03bjnSpDlFC nDReZksQnS5LZ/qgYO6iuoxkKp4et9ucFZPGLoz4tNdW6Ai17IKFuK1VfgeFZFdMoUqhsUbuzi7fr B6xzXJlE2qJTBwzszqvijt95S4BREba5QYOcaunHNdqk587W0IFBmhjwlpa7riXERIEk1+skacZlg Js6SZa5MmQvqXsAQ0EYAMY6RR4wwgfZIAPRxiP2AI/BwE63K/2/Gz4lXUOAm4OV1QESuHRJ0lS9Mw YL3WLeEfhtxC/MkKZkUIIw==; Original-Received: from [87.69.77.57] (port=1259 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg5Jn-0000na-S9; Thu, 28 Oct 2021 09:19:44 -0400 In-Reply-To: (message from Richard Stallman on Thu, 28 Oct 2021 08:19:41 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:278098 Archived-At: > From: Richard Stallman > Cc: larsi@gnus.org, galex-713@galex-713.eu, emacs-devel@gnu.org > Date: Thu, 28 Oct 2021 08:19:41 -0400 > > Imagine that one region of the buffer is displayed in two side-by-side > columns. The top of the window is in that region. To redisplay it, > display needs to know where in the buffer each column starts. > For the second column, it also needs to know how many screen lines (or > how much screen height) is off the top of the window. > > It can fill up the first column's rectangle by processing text linearly > from the window start, line by line, and putting the result into the > correct part of each screen line. > > It can fill up the second column's rectangle by processing text > linearly from the proper place in the buffer (where the right column > text should start), line by line, and putting the result into the > correct part of each screen line. > > I am thinking about non-graphics terminals. For graphics terminals, > the data structure will have to be different. (They already use a > different data structure.) > > The point is, there is no need to change the representation of buffers. You are describing the initial thorough display of a window, whereby the display engine produces the display of the entire window from scratch. That is indeed a relatively easy job, but it is quite an infrequent use case in practice. Most of the jobs that the display engine needs to do have to do with redrawing only small parts of the window, or scrolling the window by a small number of lines, or even with just moving point via cursor-motion commands. For these situations, it is very important to be able to find the buffer position that corresponds to some screen coordinates, or vice versa. We currently do that by simulating redisplay, i.e. by performing all the layout decisions without actually storing the produced glyphs. The problem is that all those jobs need to start from some well-known point in the buffer, where we can know the corresponding screen coordinates. And having the buffer text as an unstructured stream of bytes makes it hard to find such places. More often than not, we use the beginnings of some physical line, where at least the X coordinate is known to be zero. We then go through the buffer, one character at a time, performing layout calculations to track the X and Y coordinates, until we come to the place we need -- either where some condition about the buffer position becomes true, or some condition regarding the screen coordinates becomes true. This painstaking iteration from a well-known point is what makes redisplay slow in some situations, for example if the lines are very long (which means the beginning of the previous line could be very far away, and we need to examine a large fraction of the buffer). It also makes movement back in the buffer much slower (and here the variable-length internal encoding of characters joins the previous problem to make it harder). For example, imagine that the user moves the cursor to the right of the rightmost character of the first column, with the intent to move to the second column. We'd now need to find the buffer position that corresponds to that screen position, and the only way we have now is to start from the window-start of the second column and go all the way down until we reach the same Y coordinate. Imagine how much faster we could do that job if we kept record of the beginning of each screen line. So for those other jobs that redisplay must do, which in practice are much more important and frequent than redrawing the entire window, the current implementation of buffer text puts a limit on the speed, and IME we have all but exhausted all the potential for speeding that up without changing the buffer representation. Which is why I think we should change the buffer text representation if we want a faster redisplay, especially if we want to introduce complications like multiple columns etc, and still have reasonably performant redisplay.