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

[Eli Zaretskii]

> 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.

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