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

[Stephen Berman]

On Tue, 22 Jan 2019 18:25:23 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Andreas Politz <politza@hochschule-trier.de>, rudalics@gmx.at,
>> 34138@debbugs.gnu.org, tsdh@gnu.org
>> Date: Mon, 21 Jan 2019 23:27:58 +0100
>> 
>> I did this and have attached the traces.  Both show the PDF files (I
>> used different ones in each Emacs) being opened early in the trace: in
>> emacs-26 the image was immediately displayed and the trace continued and
>> then paused and I killed emacs; in emacs-master the first trace lines
>> showing the PDF file correspond to the raw PDF being displayed,
>> following by the same kind of trace lines as in emacs-26, but then two
>> lines with the PDF file again, which is when the image display appeared,
>> after which the trace paused and I killed emacs.  As in all my other
>> test runs, here again the image appeared without any keyboard input, but
>> interestingly and surprisingly, this time it took less than 10 seconds,
>> as compared to 30-60 seconds in most of the other runs (which were
>> without tracing).
>
> Thanks.
>
> 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?

> P.S. Any reason why one trace shows R-lang.pdf, whereas the other
> R-data.pdf?

I made the emacs-26 trace first, and wanted to exclude the possibility
that there could be some trace of the PDF in the machine memory that
could affect the emacs-master trace (no idea if that is possible).  This
time I made the emacs-master trace first and used the same file for the
emacs-26 trace.  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
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.

Steve Berman

trace-emacs-26
Description: Binary data

trace-emacs-master
Description: Binary data