From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#34138: 27.0.50; Delayed display of PDF file images Date: Wed, 23 Jan 2019 18:13:41 +0200 Message-ID: <83lg3b8i8a.fsf@gnu.org> References: <871s58e4gh.fsf@gmx.net> <87h8e3h90z.fsf@gmx.net> <5C4483B7.1060604@gmx.at> <87d0orgz0a.fsf@gmx.net> <837eezbazk.fsf@gnu.org> <878szfgwdu.fsf@gmx.net> <8336pnb9cq.fsf@gnu.org> <874la3gujy.fsf@gmx.net> <831s57b7ev.fsf@gnu.org> <87zhrvfdzu.fsf@gmx.net> <83zhrv9qe5.fsf@gnu.org> <87sgxnf48d.fsf@gmx.net> <83pnsq9f47.fsf@gnu.org> <871s56dm5q.fsf@gmx.net> <83lg3e9dd6.fsf@gnu.org> <87womxdgdq.fsf@gmx.net> <83fttlam3b.fsf@gnu.org> <87sgxlrfgg.fsf@hochschule-trier.de> <83bm49aj3q.fsf@gnu.org> <87a7jtd4sx.fsf@gmx.net> <834la0accs.fsf@gnu.org> <87lg3cfjef.fsf@gmx.net> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="20251"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 34138@debbugs.gnu.org, politza@hochschule-trier.de, tsdh@gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 23 17:26:26 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gmLEt-0000zR-Cu for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Jan 2019 17:18:55 +0100 Original-Received: from localhost ([127.0.0.1]:37614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gmLDi-0004Wq-J3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Jan 2019 11:17:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gmLAB-0001pr-4D for bug-gnu-emacs@gnu.org; Wed, 23 Jan 2019 11:14:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gmLAA-0005XQ-2p for bug-gnu-emacs@gnu.org; Wed, 23 Jan 2019 11:14:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43679) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gmLA9-0005W7-VG for bug-gnu-emacs@gnu.org; Wed, 23 Jan 2019 11:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gmLA9-0004JE-P1 for bug-gnu-emacs@gnu.org; Wed, 23 Jan 2019 11:14:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Jan 2019 16:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34138 X-GNU-PR-Package: emacs Original-Received: via spool by 34138-submit@debbugs.gnu.org id=B34138.154826004016550 (code B ref 34138); Wed, 23 Jan 2019 16:14:01 +0000 Original-Received: (at 34138) by debbugs.gnu.org; 23 Jan 2019 16:14:00 +0000 Original-Received: from localhost ([127.0.0.1]:42960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmLA7-0004Ir-TA for submit@debbugs.gnu.org; Wed, 23 Jan 2019 11:14:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmLA5-0004Ib-4D for 34138@debbugs.gnu.org; Wed, 23 Jan 2019 11:13:58 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gmL9z-0005PF-3Z; Wed, 23 Jan 2019 11:13:51 -0500 Original-Received: from [176.228.60.248] (port=3532 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gmL9y-0003AD-K9; Wed, 23 Jan 2019 11:13:50 -0500 In-reply-to: <87lg3cfjef.fsf@gmx.net> (message from Stephen Berman on Tue, 22 Jan 2019 23:00:01 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:154703 Archived-At: > From: Stephen Berman > Cc: politza@hochschule-trier.de, rudalics@gmx.at, 34138@debbugs.gnu.org, tsdh@gnu.org > Date: Tue, 22 Jan 2019 23:00:01 +0100 > > > So could you please add the following 2 lines: > > > > fprintf (stderr, "run_window_configuration_change_hook: %p\n", f); > > fflush (stderr); > > > > into the very beginning of run_window_configuration_change_hook (it is > > in src/window.c), compile both versions of Emacs, and run the same > > scenario again. Then please show the traces, where the above message > > should be visible somewhere among the other trace messages. > > Attached. It's striking that in the emacs-26 trace > run_window_configuration_change_hook is called just once, before the PDF > (image) is displayed, while in the emacs-master trace it's called once > before the (raw) PDF is displayed and again immediately after that, but > not again when the display changes to the image. Does that accord with > your theory? Yes, sort of. (The first invocation of run_window_configuration_change_hook is AFAIU not relevant to the issue at hand, it's about a different buffer, called "manual". Only the second call is relevant.) Here's my theory: in Emacs 26, run_window_configuration_change_hook is called from various functions in window.c, which are called from Lisp, i.e. by definition _before_ redisplay. The recent changes installed by Martin replace all those calls in window.c by simply setting a flag, which is then tested in run_window_change_functions, which now calls run_window_configuration_change_hook. The crucial aspect of this change is that run_window_change_functions is called at the very end of a redisplay cycle, after redisplay_internal already finished examining all the windows, and after the call to update_frame which delivers the necessary changes to the glass. Now, image-mode works by changing an overlay. Changes in overlays are examined by the display engine, and windows displaying buffers where overlays have been changed have the corresponding portions redrawn. Windows that don't have any overlay changes and whose buffer text didn't change are skipped by redisplay, on the assumption that nothing has changed in them that requires displaying some of its part anew. And since run_window_configuration_change_hook is called only _after_ the display engine already examined the windows, it cannot trigger redisplay of the window where we show the image of the PDF document. Thus, the image is shown only upon next more or less thorough redisplay, which redraws the window in question. Therefore, a question to Martin: why was the call to run_window_change_functions put at the very end of redisplay_internal? Is this intentional, and if so, what were the reasons for that? If there are good reasons for keeping the call where it is now (e.g., moving it to beginning of the redisplay cycle will harm some legitimate use cases), we will have to come with some complementary measures to avoid breaking image-mode and its ilk. > This time with emacs-master about 25 seconds elapsed > between the raw PDF appearing in the buffer and the image appearing > (again without keyboard intervention). Immediately after that, the > trace stopped for a number of seconds (I didn't time it but I guess > 5-10), then it printed: > redisplay_preserve_echo_area (8) > redisplay_internal 0 These two traces are not in the trace you posted, right? Because the Emacs 27 trace ends with this: > redisplay_preserve_echo_area (9) > redisplay_internal 0 > 0x2a01550 (R-admin.pdf): same window start > 0x2a01550 (R-admin.pdf): 1 which I believe is the first redisplay cycle which shows the image. Right? > and then I killed the buffer. As the emacs-26 trace shows, after the > PDF image appeared (which it did without the raw PDF being displayed), > the trace rapidly produced another 50 lines of output (included in the > attachment) before pausing, after which I killed emacs. Most of the traces come from the code that invokes timers, so I think you have timers running which eventually trigger redisplay, something that doesn't happen on Andreas's machine. That might explain why you see the image after a short delay, while Andreas needs to manually trigger redisplay for that. Thanks.