From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#45898: 27.1; wedged in redisplay again Date: Sat, 25 Jun 2022 06:54:19 +0200 Message-ID: <0B5FE52E-BC81-4A05-86F1-91C6AFCB6F7D@gmail.com> References: <46b65e3f-cf3d-a3f2-9a9a-100e58274ff6@jovi.net> <8335gf5er3.fsf@gnu.org> <87leu686z4.fsf@gnus.org> <83sfoe2k0j.fsf@gnu.org> <87zgim6qtt.fsf@gnus.org> <83mtem2dc9.fsf@gnu.org> <87y1y63qmq.fsf@gnus.org> <83h74t3k5u.fsf@gnu.org> <87tu8sx569.fsf@gnus.org> <83v8t6us8t.fsf@gnu.org> <87zgiinptk.fsf@gnus.org> <83mteiufih.fsf@gnu.org> <877d5kojbo.fsf@gnus.org> <83zgigu3e0.fsf@gnu.org> <500e4b9c69f2a90e7cf05b956178d71b@webmail.orcon.net.nz> <835yl3tnv3.fsf@gnu.org> <83iloyo0x7.fsf@gnu.org> <83mte5jukr.fsf@gnu.org> <837d57gbed.fsf@gnu.org> <83o7yicx3p.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_4C868E66-B48E-4883-B336-437361CDAF3E" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21540"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 45898@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 25 06:55:20 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1o4xpH-0005Rw-2I for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Jun 2022 06:55:19 +0200 Original-Received: from localhost ([::1]:48552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o4xpF-0000g7-Lo for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Jun 2022 00:55:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36790) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o4xp0-0000dp-5B for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2022 00:55:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50064) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o4xoz-0004E1-RB for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2022 00:55:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o4xoz-0008BJ-Qb for bug-gnu-emacs@gnu.org; Sat, 25 Jun 2022 00:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Jun 2022 04:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45898 X-GNU-PR-Package: emacs Original-Received: via spool by 45898-submit@debbugs.gnu.org id=B45898.165613287131408 (code B ref 45898); Sat, 25 Jun 2022 04:55:01 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 25 Jun 2022 04:54:31 +0000 Original-Received: from localhost ([127.0.0.1]:43961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4xoV-0008AW-9u for submit@debbugs.gnu.org; Sat, 25 Jun 2022 00:54:31 -0400 Original-Received: from mail-ej1-f54.google.com ([209.85.218.54]:36742) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o4xoT-0008AI-BA for 45898@debbugs.gnu.org; Sat, 25 Jun 2022 00:54:30 -0400 Original-Received: by mail-ej1-f54.google.com with SMTP id cw10so8512807ejb.3 for <45898@debbugs.gnu.org>; Fri, 24 Jun 2022 21:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nMtFVa9iawBoDQw3SFamxsCuCvS19ycipz1/F8oGZ84=; b=ZM7TVQRPlq0IvGE+ippO5qC3JcF9xr6KAxPCT8gnPy+a54bUQ3QmVUiDlNd9J2iiQC NhbqcChdBe2Tb5tZQmwaU/cmL31eG7/XT5h1hdNhOgwH5AcNyLQihkxQOiXV0nBOjj7S E1gAsNExMjMMSKVg9IVFGrzHfyQjeNUr8QiHYg/YXUaWw+TmJrSSx8RoQBrr+d5oVPTN kzEeiy6DFarIPo5kYWzgHpZ2ZK6w82QSieJRWjo+bgbun/MBwGEvIZ/t6n7BKuuFeOmg /oQEXY5pIzYt8siPgQJ0bfdg/jAjD1xzEqzyGqp+4wYghiA8hfGxOJ4zaCZMc1kpfTuC smig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=nMtFVa9iawBoDQw3SFamxsCuCvS19ycipz1/F8oGZ84=; b=O2e6cbOsjod2e/0qa6ij1DjD+igZJenECBkYi/Z28Xdki+2EmG2g6Ck63kXVApxqAD Dr9HfCNFV07Iw/BKz8EnRhT4eS/5cKTNzbcVgFKUZKWAOzn5uxUdNTO8lzqUYxuJFTOE RTxk29YthVmekK/pzvtiusc4oWoWvogEbFNhBVfja6fhcQqK4xTHkDKZCQFvKFj3vVWj dzMEBfZDXJAxQjRbasmgmcJ3G92pJeNFCneuHp2Y4QVNJMLoOStoa5ev6gHmU5+MM9gh A6Bt2l5lNudYforjvERyUiMxVVsGnl104FOZuBZRZGxWDtWty78emRBt3SipVosK5yk+ XGOA== X-Gm-Message-State: AJIora99gF39Re7bCdJabU/LU0ni3UX4gZxrCPMJEjpnaFMRVMfzBC6J PhBNvqtP0cU5iwrlwFLoQFE= X-Google-Smtp-Source: AGRyM1vDXDhwp6GI6MlNxqTMFuxxHUJUPJsXamfDJ0mSc1hlStNQuGOselkJV03/FtQP8/65SQm7Pg== X-Received: by 2002:a17:906:530b:b0:722:e9ad:e90 with SMTP id h11-20020a170906530b00b00722e9ad0e90mr2340278ejo.676.1656132862907; Fri, 24 Jun 2022 21:54:22 -0700 (PDT) Original-Received: from smtpclient.apple (p4fe3a040.dip0.t-ipconnect.de. [79.227.160.64]) by smtp.gmail.com with ESMTPSA id hb10-20020a170906b88a00b007266185ca67sm107917ejb.150.2022.06.24.21.54.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jun 2022 21:54:22 -0700 (PDT) In-Reply-To: <83o7yicx3p.fsf@gnu.org> X-Mailer: Apple Mail (2.3696.100.31) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:235230 Archived-At: --Apple-Mail=_4C868E66-B48E-4883-B336-437361CDAF3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2022-06-24,, at 9:57 , Eli Zaretskii wrote: >=20 >=20 > Gerd, your comments will be most appreciated, TIA. >=20 I didn=E2=80=99t read the whole thread in the bug report, but i think I = understand the gist of the matter, from our recent conversation, and = from reading the change set.=20 I think it helps me in the following when I briefly describe the model = of Emacs=E2=80=99 internals I have in my head. That way, I can write = about things in terms in which I think. So, let me try. When I think = of Emacs' design, I think of functions and categories they belong to. = Categories in the sense of animal, dog, human, plant. A bit like = modules, but not quite, but if it=E2=80=99s helpful, just think of = modules instead.=20 The categories I'd like to use here, are lisp, redisplay, iterator, = update, regexp. I leave the rest out. Here is what I group under these = categories: Lisp Eval, funcall API for buffers, windows, etc ... Iterator Walk over text in display order (including bidi, display = strings) Determine current character, image Keep track of pixel (x y w h) (x y) <-> text position computation Redisplay Produce desired glyphs=20 Produce as few as possible (optimizations) Update Bring desired glyphs to the screen Regexp=20 Matching and searching support That=E2=80=99s why I=E2=80=99m sometimes slow when redisplay is used for = what I call iterator.=20 If -> denotes "uses", or "calls into", we have Lisp=20 -> iterator in (x y) <-> text pos=20 -> regexp=20 -> redisplay (I think, Fredisplay?) Redisplay=20 -> iterator=20 -> lisp (hooks) Iterator -> Lisp (eval funcall hooks) Update=20 -> maybe hook, I don=E2=80=99t remember Regexp=20 -> lisp, I=E2=80=99ve heard Very roughly, and much too long, sorry for that. What I so far understand about your design, and i haven't looked at = details: One of the first things that came to my mind is a new category "time = fuse" (in German Zeitz=C3=BCnder), something counting ticks, and = detonating (signaling) at some point. I admit that I find the names you = used with redisplay in them confusing. Especially in the regexp code = and so. Functionality-wise, Iterator now signals an error that redisplay = catches.=20 The error is signaled when a global tick counter exceeds a max value. = Each movement of an iterator increments the global tick counter. The = counter is global because you want to sum up all the ticks that occur = between a given start point where the tick counter is set to 0, and the = point where the ticks exceed the maximum, regardless of iterator -> lisp = -> iterator nesting. The global tick counter is also incremented from regexp. I think = font-lock plays a role here. One scenario is redisplay or lisp -> = iterator, iterator needs font-lock to run (-> lisp), font-lock matches a = regexp (lisp -> regexp), and we get stuck on a long line. Likewise with = other stuff, like syntax. Good. (BTW, the call to update the tick in regexp can lead to a GC when the = error is signaled, in the same way as in bug 56108 with maybe_quit. So = we might need that, too.) Maybe we could disable the calls cheaply when max-ticks is 0? I mean, = something that inlines if (max_ticks > 0) update_ticks(...) I would have a better gut feeling in that case, wrt older machines. Not = that I notice a slowdown on my machine, but I'm building with ASan = enabled, so everything is kinda slow anyway. The meaning of display_working_on_window_p is not clear to me. I see = what setting it does in the end, but I can't tell what this means: /* True while some display-engine code is working on layout of some window. Probably good. Do you want me to take a deeper look at specific places? --Apple-Mail=_4C868E66-B48E-4883-B336-437361CDAF3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 2022-06-24,, at 9:57 , Eli Zaretskii <eliz@gnu.org> = wrote:


Gerd, your comments will be most appreciated, = TIA.


I didn=E2=80=99t read the whole thread in the = bug report, but i think I understand the gist of the matter, from our = recent conversation, and from reading the change set. 

I think it helps me = in the following when I briefly describe the model of Emacs=E2=80=99 = internals I have in my head.  That way, I can write about things in = terms in which I think.  So, let me try.  When I think of = Emacs' design, I think of functions and categories they belong to.  = Categories in the sense of animal, dog, human, plant.   A bit like = modules, but not quite, but if it=E2=80=99s helpful, just think of = modules instead. 

The categories I'd like to use here, are lisp, = redisplay, iterator, update, regexp.   I leave the rest out. Here = is what I group under these categories:

Lisp
Eval, funcall
= API for buffers, windows, etc
...
Iterator
= Walk over text in display order (including  bidi, display = strings)
Determine current character, = image
= Keep track of pixel (x y w h)
(x y) <-> text position = computation
Redisplay
Produce desired = glyphs 
Produce as few as possible = (optimizations)
Update
Bring desired glyphs to the = screen
Regexp 
Matching and searching = support

That=E2=80=99s why = I=E2=80=99m sometimes slow when redisplay is used for what I call = iterator. 
If -> denotes "uses", or "calls into", we = have

Lisp 
= -> iterator in (x y) <-> text pos 
= -> regexp 
-> redisplay (I think, = Fredisplay?)
Redisplay 
-> iterator 
= -> lisp (hooks)
Iterator
= -> Lisp (eval funcall hooks)
Update 
= -> maybe hook, I don=E2=80=99t remember
Regexp 
-> lisp, I=E2=80=99ve = heard

Very roughly, and = much too long, sorry for that.

What I so far understand about your design, and = i haven't looked at details:

One of the first things that came to my mind is = a new category "time fuse" (in German Zeitz=C3=BCnder), something = counting ticks, and detonating (signaling) at some point.  I admit = that I find the names you used with redisplay in them confusing.  = Especially in the regexp code and so.

Functionality-wise, Iterator now signals an = error that redisplay catches. 

The error is signaled when a global tick counter = exceeds a max value.  Each movement of an iterator increments the = global tick counter.  The counter is global because you want to sum = up all the ticks that occur between a given start point where the tick = counter is set to 0, and the point where the ticks exceed the maximum, = regardless of iterator -> lisp -> iterator nesting.

The global tick = counter is also incremented from regexp.  I think font-lock plays a = role here.  One scenario is redisplay or lisp -> iterator, = iterator needs font-lock to run (-> lisp), font-lock matches a regexp = (lisp -> regexp), and we get stuck on a long line.  Likewise = with other stuff, like syntax.

Good.

(BTW, the call to update the tick in regexp can = lead to a GC when the error is signaled, in the same way as in bug 56108 = with maybe_quit.  So we might need that, too.)

Maybe we could = disable the calls cheaply when max-ticks is 0?  I mean, something = that inlines

= if (max_ticks > 0)
        =   update_ticks(...)

I would have a better gut feeling in that case, = wrt older machines.  Not that I notice a slowdown on my machine, = but I'm building with ASan enabled, so everything is kinda slow = anyway.

The meaning of = display_working_on_window_p is not clear to me.  I see what setting = it does in the end, but I can't tell what this means:

/* True while some = display-engine code is working on layout of some
   window.

Probably good.

Do you want me to take a deeper look at specific = places?


= --Apple-Mail=_4C868E66-B48E-4883-B336-437361CDAF3E--