bug#34138: 27.0.50; Delayed display of PDF file images

[Stephen Berman <stephen.berman@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

On Tue, 22 Jan 2019 22:54:16 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Tue, 22 Jan 2019 18:25:23 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>> I have a theory, but I need evidence to convince myself that my theory
>> is sound.  I need to see where in the series of traces produced by
>> trace-redisplay we call run_window_configuration_change_hook, in both
>> versions of Emacs.
>>
>> 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?

I found that the following patch to pdf-view-goto-page eliminates the
display of raw PDF and the delay of the image display:

*** /home/steve/.emacs.d/elpa/pdf-tools-20181221.1913/pdf-view.el.orig	2019-01-21 15:56:08.033335212 +0100
--- /home/steve/.emacs.d/elpa/pdf-tools-20181221.1913/pdf-view.el	2019-01-23 14:54:52.381373638 +0100
***************
*** 624,629 ****
--- 624,630 ----
          (pdf-view-deactivate-region)
          (force-mode-line-update)
          (run-hooks 'pdf-view-after-change-page-hook))))
+   (switch-to-buffer (current-buffer))
    nil)
  
  (defun pdf-view-next-page (&optional n)

I assume this is only a workaround.  I've also attached the redisplay
trace using this patch; it looks almost the same as the trace without
this patch except for lacking the repetition of the PDF buffer display
(which is where the change to the image display occurs without the
patch).

Steve Berman


[-- Attachment #2: trace-emacs-master-2 --]
[-- Type: application/octet-stream, Size: 1654 bytes --]

redisplay_preserve_echo_area (2)
redisplay_internal 0
0x1826350 (manual): same window start
0x1826350 (manual): 1
run_window_configuration_change_hook: 0x1826140
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0
0x1826350 (R-admin.pdf): same window start
0x1826350 (R-admin.pdf): 1
run_window_configuration_change_hook: 0x1826140
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
redisplay_internal 0