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

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

On Wed, 23 Jan 2019 18:13:41 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> 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.

"manual" is the Dired buffer of the directory containing the PDF file.

>                             )
>
> Here's my theory: [...]

Thanks, this sounds plausible.

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

Yes.  The trace I posted ends at that point, but as I wrote above, after
5-10 seconds of no further traces, the above two lines appeared, and
then I killed the buffer.  I mentioned that in case it might be
relevant.  Sorry for the confusion.

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

Ah, that seems likely.  I do have several timers running, I'll see if I
can deactivate them and whether that results in no image display.

Steve Berman