From: Stephen Berman <stephen.berman@gmx.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 34138@debbugs.gnu.org, politza@hochschule-trier.de, tsdh@gnu.org
Subject: bug#34138: 27.0.50; Delayed display of PDF file images
Date: Tue, 22 Jan 2019 23:00:01 +0100 [thread overview]
Message-ID: <87lg3cfjef.fsf@gmx.net> (raw)
In-Reply-To: <834la0accs.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 22 Jan 2019 18:25:23 +0200")
[-- Attachment #1: Type: text/plain, Size: 3133 bytes --]
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
[-- Attachment #2: trace-emacs-26 --]
[-- Type: application/octet-stream, Size: 1606 bytes --]
redisplay_preserve_echo_area (2)
redisplay_internal 0
0x1314c30 (manual): same window start
0x1314c30 (manual): 1
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
run_window_configuration_change_hook: 0x1313c30
redisplay_internal 0
0x1314c30 (R-admin.pdf): same window start
0x1314c30 (R-admin.pdf): 1
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
[-- Attachment #3: trace-emacs-master --]
[-- Type: application/octet-stream, Size: 1886 bytes --]
redisplay_preserve_echo_area (2)
redisplay_internal 0
0x2a01550 (manual): same window start
0x2a01550 (manual): 1
run_window_configuration_change_hook: 0x2a01340
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_internal 0
0x2a01550 (R-admin.pdf): same window start
0x2a01550 (R-admin.pdf): 1
run_window_configuration_change_hook: 0x2a01340
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
redisplay_preserve_echo_area (8)
redisplay_internal 0
redisplay_preserve_echo_area (9)
redisplay_internal 0
0x2a01550 (R-admin.pdf): same window start
0x2a01550 (R-admin.pdf): 1
next prev parent reply other threads:[~2019-01-22 22:00 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-19 21:13 bug#34138: 27.0.50; Delayed display of PDF file images Stephen Berman
2019-01-20 9:17 ` martin rudalics
2019-01-20 11:04 ` Andreas Politz
2019-01-20 14:19 ` martin rudalics
2019-01-20 11:18 ` Stephen Berman
2019-01-20 14:20 ` martin rudalics
2019-01-20 14:55 ` Stephen Berman
2019-01-20 15:32 ` Eli Zaretskii
2019-01-20 15:51 ` Stephen Berman
2019-01-20 16:08 ` Eli Zaretskii
2019-01-20 16:31 ` Stephen Berman
2019-01-20 16:50 ` Eli Zaretskii
2019-01-20 17:14 ` Stephen Berman
2019-01-20 17:42 ` Eli Zaretskii
2019-01-20 20:45 ` Stephen Berman
2019-01-21 15:58 ` Eli Zaretskii
2019-01-21 16:13 ` Stephen Berman
2019-01-21 16:36 ` Eli Zaretskii
2019-01-21 18:17 ` Stephen Berman
2019-01-21 18:42 ` Eli Zaretskii
2019-01-21 19:14 ` Andreas Politz
2019-01-21 19:47 ` Eli Zaretskii
2019-01-21 22:27 ` Stephen Berman
2019-01-22 16:25 ` Eli Zaretskii
2019-01-22 22:00 ` Stephen Berman [this message]
2019-01-23 14:31 ` Stephen Berman
2019-01-23 16:26 ` Eli Zaretskii
2019-01-23 17:22 ` Stephen Berman
2019-01-23 16:13 ` Eli Zaretskii
2019-01-23 17:21 ` Stephen Berman
2019-01-23 22:20 ` Stephen Berman
2019-01-23 18:27 ` martin rudalics
2019-01-23 18:39 ` Eli Zaretskii
2019-01-24 9:08 ` martin rudalics
2019-01-24 14:26 ` Eli Zaretskii
2019-01-24 19:41 ` Andreas Politz
2019-01-25 9:44 ` martin rudalics
2019-01-26 9:19 ` martin rudalics
2019-01-26 10:52 ` Eli Zaretskii
2019-01-26 15:07 ` martin rudalics
2019-01-26 15:33 ` Stephen Berman
2019-02-02 9:28 ` martin rudalics
2019-02-02 9:38 ` Andreas Politz
2019-02-19 8:47 ` martin rudalics
2019-02-02 12:59 ` Stephen Berman
2019-02-19 8:40 ` martin rudalics
2019-03-30 2:56 ` Noam Postavsky
2019-04-23 9:22 ` martin rudalics
2019-02-02 9:33 ` Andreas Politz
2019-02-02 9:37 ` martin rudalics
2019-01-21 20:33 ` Stephen Berman
2019-01-21 20:35 ` Eli Zaretskii
2019-01-21 20:43 ` Stephen Berman
2019-01-21 21:28 ` Andreas Politz
2019-01-21 18:47 ` martin rudalics
2019-01-21 19:19 ` Andreas Politz
2019-01-21 20:33 ` Stephen Berman
2019-01-20 17:55 ` martin rudalics
2019-01-20 20:45 ` Stephen Berman
2019-01-21 7:52 ` martin rudalics
2019-01-21 15:20 ` Stephen Berman
2019-01-21 6:11 ` Tassilo Horn
2019-01-21 7:52 ` martin rudalics
2019-01-21 15:20 ` Stephen Berman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lg3cfjef.fsf@gmx.net \
--to=stephen.berman@gmx.net \
--cc=34138@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=politza@hochschule-trier.de \
--cc=tsdh@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.