bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stephen Berman
Subject: bug#34138: 27.0.50; Delayed display of PDF file images
Date: Mon, 21 Jan 2019 19:17:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

On Mon, 21 Jan 2019 18:36:37 +0200 Eli Zaretskii <address@hidden> wrote:

>> From: Stephen Berman <address@hidden>
>> Cc: address@hidden, address@hidden, address@hidden,
>> address@hidden
>> Date: Mon, 21 Jan 2019 17:13:05 +0100
>> 
>> > Still weird: this says that Emacs simply waits for any input to
>> > arrive, a.k.a. "is idle".
>> >
>> > You've mentioned before that one of the two scenarios where you see
>> > this problem produces a much longer delay -- could you repeat the same
>> > procedure during that long delay, and show the backtrace from that
>> > session?  Maybe we will see something more interesting there.
>> 
>> This (and all the other backtraces I posted or mentioned) was from the
>> scenario where I see the long delay, i.e. using pdf-view-mode
>
> So does it mean that during this time Emacs waits for the external
> process (is it Ghostscript? ImageMagick?) to complete?  That's all I
> see in the backtrace.

Not Ghostscript but the PDF rendering library Poppler; I think
ImageMagick can be used for some functionality, but it's not required.
But Andreas Politza can surely answer this best and provide more details.

> Can you establish (e.g., by adding 'message' lines to the Lisp source)
> where in the pdf-view-mode's sources this delay starts?  IOW, what is
> the last thing pdf-view-mode does before the delay begins?

I don't know where it makes sense to output messages.  I did step
through pdf-view-mode and the last function it calls,
pdf-view-goto-page, but when that function returns it's just the raw PDF
that's displayed.  I then instrumented all pdf-view defuns and while
stepping though, the PDF image appeared on calling
pdf-view-maybe-redisplay-resized-windows, which is added to
window-configuration-change-hook in pdf-view-mode.  So it appears that
the delay starts between pdf-view-goto-page returning and
pdf-view-maybe-redisplay-resized-windows being called, but when stepping
through the long call chain, I did not see the transition (no raw PDF
was displayed, just the rendered image at the end).

Steve Berman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]