* bug#14838: 24.3.50; repeating next-line or previous-line is broken @ 2013-07-10 21:29 Stephen Berman 2013-07-11 2:51 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Stephen Berman @ 2013-07-10 21:29 UTC (permalink / raw) To: 14838 Starting with revision 113314, I observe the following: 0. emacs -Q 1. C-h n to visit NEWS 2. Type C-n and hold the keys down to repeatedly move point down one line. At around line 250, the motion gets jerky and then appears to stop, and the cursor disappears. After releasing the keys (but with a delay of maybe a second or longer, perhaps depending on how long they were held down), the cursor reappears on a line further down (which one seems to depend on how long the keys were held down). Subsequently holding down C-n or C-p makes the cursor vanish and motion stop almost immediately, until the keys are released. The same thing happens if, after step 1 above, I type M-> and then hold down C-p (the stop seems to happen a bit later, maybe after moving up about 300 lines). With the revision 113360 (this one), the misbehavior begins almost immediately with C-n, though with C-p it appears to be the same as above. When the motion starts getting jerky, my CPU load starts shooting up, and hits 90%+ when the cursor disappears and motion stops, and stays at that load until the cursor reappears at the new location. My processor is an AMD Sempron 3400+ (64bit) with a maximum speed of 1.8GHz. In addition to the following system information, my desktop environment is KDE 4.9.5. My default font with emacs -Q is xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1 In GNU Emacs 24.3.50.12 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4) of 2013-07-10 on rosalinde Bzr revision: 113360 eliz@gnu.org-20130710161817-qw8stt9m23a285vy Windowing system distributor `The X.Org Foundation', version 11.0.11203000 System Description: openSUSE 12.2 (x86_64) Configured using: `configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0' Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=local locale-coding-system: utf-8-unix default enable-multibyte-characters: t ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-10 21:29 bug#14838: 24.3.50; repeating next-line or previous-line is broken Stephen Berman @ 2013-07-11 2:51 ` Eli Zaretskii 2013-07-11 10:04 ` Stephen Berman 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2013-07-11 2:51 UTC (permalink / raw) To: Stephen Berman; +Cc: 14838 > From: Stephen Berman <stephen.berman@gmx.net> > Date: Wed, 10 Jul 2013 23:29:12 +0200 > > Starting with revision 113314, I observe the following: > > 0. emacs -Q > 1. C-h n to visit NEWS > 2. Type C-n and hold the keys down to repeatedly move point down one line. > > At around line 250, the motion gets jerky and then appears to stop, and > the cursor disappears. After releasing the keys (but with a delay of > maybe a second or longer, perhaps depending on how long they were held > down), the cursor reappears on a line further down (which one seems to > depend on how long the keys were held down). Subsequently holding down > C-n or C-p makes the cursor vanish and motion stop almost immediately, > until the keys are released. The same thing happens if, after step 1 > above, I type M-> and then hold down C-p (the stop seems to happen a bit > later, maybe after moving up about 300 lines). > > With the revision 113360 (this one), the misbehavior begins almost > immediately with C-n, though with C-p it appears to be the same as > above. > > When the motion starts getting jerky, my CPU load starts shooting up, > and hits 90%+ when the cursor disappears and motion stops, and stays at > that load until the cursor reappears at the new location. > > My processor is an AMD Sempron 3400+ (64bit) with a maximum speed of > 1.8GHz. In addition to the following system information, my desktop > environment is KDE 4.9.5. My default font with emacs -Q is > xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1 Does using a different font change anything? To see which function takes most of the time, please use profiler-start, press C-n, then after you see CPU load for some time, invoke profiler-report. It is best to do that after manually loading simple.el in source form. Also, apply the patch I sent in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14836#8 and post the contents of *Messages* after leaning on C-n for some time in this situation. I also asked to try reducing the keyboard auto-repeat rate, and see if that makes any difference. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-11 2:51 ` Eli Zaretskii @ 2013-07-11 10:04 ` Stephen Berman 2013-07-11 15:59 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Stephen Berman @ 2013-07-11 10:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 14838 On Thu, 11 Jul 2013 05:51:52 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <stephen.berman@gmx.net> >> Date: Wed, 10 Jul 2013 23:29:12 +0200 >> >> Starting with revision 113314, I observe the following: >> >> 0. emacs -Q >> 1. C-h n to visit NEWS >> 2. Type C-n and hold the keys down to repeatedly move point down one line. >> >> At around line 250, the motion gets jerky and then appears to stop, and >> the cursor disappears. After releasing the keys (but with a delay of >> maybe a second or longer, perhaps depending on how long they were held >> down), the cursor reappears on a line further down (which one seems to >> depend on how long the keys were held down). Subsequently holding down >> C-n or C-p makes the cursor vanish and motion stop almost immediately, >> until the keys are released. The same thing happens if, after step 1 >> above, I type M-> and then hold down C-p (the stop seems to happen a bit >> later, maybe after moving up about 300 lines). >> >> With the revision 113360 (this one), the misbehavior begins almost >> immediately with C-n, though with C-p it appears to be the same as >> above. >> >> When the motion starts getting jerky, my CPU load starts shooting up, >> and hits 90%+ when the cursor disappears and motion stops, and stays at >> that load until the cursor reappears at the new location. >> >> My processor is an AMD Sempron 3400+ (64bit) with a maximum speed of >> 1.8GHz. In addition to the following system information, my desktop >> environment is KDE 4.9.5. My default font with emacs -Q is >> xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1 > > Does using a different font change anything? Yes. First, I found out that the problems I observed do not happen when I repeat exactly the above recipe after having removed my ~/.Xresources file and logged in again. That file contains this: Emacs.FontBackend: xft Emacs.Font: DejaVu Sans Mono-9 ! ---------[ xft ] --------- Xft*antialias: true Xft*autohint: true Without this, when I start Emacs with -Q, the font is still the one I reported above, but now holding down C-n in NEWS works fine. I don't understand why, since I thought -Q means no X resources are read. When I start Emacs with my init file but without the .Xresources file, I also don't observe the problem with C-n. In my initializations, I have the font DejaVu Sans Mono-9 set as default in a custom theme loaded from my init file (I've been using the .Xresources file since long before creating the them, and didn't try removing till now). So without the .Xresources file, I have no problem using C-n with this font, but with the above .Xresources, the problem occurs with this font. If I start Emacs with -q, the font used is now this: x:-sony-fixed-medium-r-normal--16-120-100-100-c-80-iso8859-1 Also with this font I see no problem when holding down C-n. Likewise starting with my initializations but removing DejaVu from the custom them, so with the -sony-fixed-medium-r-normal- font (which apparently comes from /usr/share/X11/app-defaults/Emacs). However, when I switch the default font (using the Options menu) to Adobe Courier, which starting with -Q is this: xft:-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1 and repeat the above recipe, now I do observe the problem. This also happens with -q and with my initializations, using Adobe Courier. > To see which function takes most of the time, please use > profiler-start, press C-n, then after you see CPU load for some time, > invoke profiler-report. It is best to do that after manually loading > simple.el in source form. I started Emacs like this: emacs -Q -l ~/bzr/emacs/quickfixes/lisp/simple.el switched the default font to Adobe Courier as described above and then followed your instructions; here is the report: + call-interactively 6758 29% + next-line 6059 26% + if 5176 22% + line-move 3875 16% + command-execute 522 2% Automatic GC 445 1% + let 86 0% + redisplay_internal (C function) 35 0% + prog1 26 0% + read-from-minibuffer 24 0% + find-file-noselect 19 0% + run-hooks 18 0% + condition-case 16 0% + cond 12 0% + view-file 8 0% + mapc 4 0% + list 4 0% + read-extended-command 4 0% + vc-mode-line 3 0% + line-move-visual 3 0% + file-truename 2 0% + vc-find-file-hook 2 0% + vc-backend 2 0% + after-find-file 2 0% + completing-read 2 0% + let* 1 0% + view-emacs-news 1 0% + find-file-noselect-1 1 0% + vc-call-backend 1 0% internal-timer-start-idle 1 0% + and 1 0% > Also, apply the patch I sent in > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14836#8 and post the > contents of *Messages* after leaning on C-n for some time in this > situation. I did this, started Emacs -Q again as above, switched the default font to Adobe Courier, and ran my recipe. *Message* consists of these lines: For information about GNU Emacs and the GNU system, type C-h C-a. bzr/emacs/quickfixes/lisp/simple.el: `with-wrapper-hook' is an obsolete macro (as of 24.4); use a <foo>-function variable modified by add-function. View mode: type C-h for help, h for commands, q to quit. followed by exactly 175 repetitions of these two lines (I used `M-x occur' to make sure they were all identical): vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0 2 and nothing else. > I also asked to try reducing the keyboard auto-repeat rate, and see if > that makes any difference. The default rate in my setup is 25 repeats/s. I lowered it to 15 and repeated the above experiment, and the problem again occurs, but starts later, around line 300. Then I lowered the repeat rate to 10, which is annoyingly slow, and here too the problem occurs, starting around line 500. Steve Berman ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-11 10:04 ` Stephen Berman @ 2013-07-11 15:59 ` Eli Zaretskii 2013-07-11 18:51 ` Stephen Berman 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2013-07-11 15:59 UTC (permalink / raw) To: Stephen Berman, Jan Djärv; +Cc: 14838 > From: Stephen Berman <stephen.berman@gmx.net> > Cc: 14838@debbugs.gnu.org > Date: Thu, 11 Jul 2013 12:04:07 +0200 > > Yes. First, I found out that the problems I observed do not happen when > I repeat exactly the above recipe after having removed my ~/.Xresources > file and logged in again. That file contains this: > > Emacs.FontBackend: xft > Emacs.Font: DejaVu Sans Mono-9 > > ! ---------[ xft ] --------- > Xft*antialias: true > Xft*autohint: true > > Without this, when I start Emacs with -Q, the font is still the one I > reported above, but now holding down C-n in NEWS works fine. I don't > understand why, since I thought -Q means no X resources are read. It should. Is inhibit-x-resources set when you invoke with -Q? Maybe the fact that X resources matter is a GTK thing? Just guessing. Jan, could you please comment on this? > When I start Emacs with my init file but without the .Xresources file, I > also don't observe the problem with C-n. In my initializations, I have > the font DejaVu Sans Mono-9 set as default in a custom theme loaded from > my init file (I've been using the .Xresources file since long before > creating the them, and didn't try removing till now). So without the > .Xresources file, I have no problem using C-n with this font, but with > the above .Xresources, the problem occurs with this font. FWIW, I tried such a font as well (but without anti-aliasing), and didn't see any problem. > I started Emacs like this: > > emacs -Q -l ~/bzr/emacs/quickfixes/lisp/simple.el > > switched the default font to Adobe Courier as described above and then > followed your instructions; here is the report: > > + call-interactively 6758 29% > + next-line 6059 26% > + if 5176 22% > + line-move 3875 16% > + command-execute 522 2% > Automatic GC 445 1% > + let 86 0% > + redisplay_internal (C function) 35 0% > + prog1 26 0% > + read-from-minibuffer 24 0% > + find-file-noselect 19 0% > + run-hooks 18 0% > + condition-case 16 0% > + cond 12 0% > + view-file 8 0% > + mapc 4 0% > + list 4 0% > + read-extended-command 4 0% > + vc-mode-line 3 0% > + line-move-visual 3 0% > + file-truename 2 0% > + vc-find-file-hook 2 0% > + vc-backend 2 0% > + after-find-file 2 0% > + completing-read 2 0% > + let* 1 0% > + view-emacs-news 1 0% > + find-file-noselect-1 1 0% > + vc-call-backend 1 0% > internal-timer-start-idle 1 0% > + and 1 0% What do you see if you completely expand the profile? Do you see line-move-partial anywhere in the profile? That's the only function where I made significant changes in the offending revisions, so if it's not high in the profile, I don't know what to think. > followed by exactly 175 repetitions of these two lines (I used `M-x > occur' to make sure they were all identical): > > vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0 > 2 > > and nothing else. The "py 0" part is very strange. "py" is the vertical coordinate of point in screen line units. Since this was with C-n, I expect py never to be less than half the screen height, which is 16. How come it is zero, i.e. point is in the first line? Can you step through line-move-partial in Edebug and see what is going on there? > > I also asked to try reducing the keyboard auto-repeat rate, and see if > > that makes any difference. > > The default rate in my setup is 25 repeats/s. I lowered it to 15 and > repeated the above experiment, and the problem again occurs, but starts > later, around line 300. Then I lowered the repeat rate to 10, which is > annoyingly slow, and here too the problem occurs, starting around line > 500. This is consistent with the high CPU load you see. But I'd be damned if I understand what is causing that CPU load, or why it happens with some fonts, but not others. Btw, do you have any local changes in your builds? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-11 15:59 ` Eli Zaretskii @ 2013-07-11 18:51 ` Stephen Berman 2013-07-11 19:16 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Stephen Berman @ 2013-07-11 18:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 14838 On Thu, 11 Jul 2013 18:59:14 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <stephen.berman@gmx.net> >> Cc: 14838@debbugs.gnu.org >> Date: Thu, 11 Jul 2013 12:04:07 +0200 >> >> Yes. First, I found out that the problems I observed do not happen when >> I repeat exactly the above recipe after having removed my ~/.Xresources >> file and logged in again. That file contains this: >> >> Emacs.FontBackend: xft >> Emacs.Font: DejaVu Sans Mono-9 >> >> ! ---------[ xft ] --------- >> Xft*antialias: true >> Xft*autohint: true >> >> Without this, when I start Emacs with -Q, the font is still the one I >> reported above, but now holding down C-n in NEWS works fine. I don't >> understand why, since I thought -Q means no X resources are read. > > It should. Is inhibit-x-resources set when you invoke with -Q? Yes, its value is t. > Maybe the fact that X resources matter is a GTK thing? Just > guessing. Jan, could you please comment on this? > >> When I start Emacs with my init file but without the .Xresources file, I >> also don't observe the problem with C-n. In my initializations, I have >> the font DejaVu Sans Mono-9 set as default in a custom theme loaded from >> my init file (I've been using the .Xresources file since long before >> creating the them, and didn't try removing till now). So without the >> .Xresources file, I have no problem using C-n with this font, but with >> the above .Xresources, the problem occurs with this font. > > FWIW, I tried such a font as well (but without anti-aliasing), and > didn't see any problem. > >> I started Emacs like this: >> >> emacs -Q -l ~/bzr/emacs/quickfixes/lisp/simple.el >> >> switched the default font to Adobe Courier as described above and then >> followed your instructions; here is the report: >> >> + call-interactively 6758 29% >> + next-line 6059 26% >> + if 5176 22% >> + line-move 3875 16% >> + command-execute 522 2% >> Automatic GC 445 1% >> + let 86 0% >> + redisplay_internal (C function) 35 0% >> + prog1 26 0% >> + read-from-minibuffer 24 0% >> + find-file-noselect 19 0% >> + run-hooks 18 0% >> + condition-case 16 0% >> + cond 12 0% >> + view-file 8 0% >> + mapc 4 0% >> + list 4 0% >> + read-extended-command 4 0% >> + vc-mode-line 3 0% >> + line-move-visual 3 0% >> + file-truename 2 0% >> + vc-find-file-hook 2 0% >> + vc-backend 2 0% >> + after-find-file 2 0% >> + completing-read 2 0% >> + let* 1 0% >> + view-emacs-news 1 0% >> + find-file-noselect-1 1 0% >> + vc-call-backend 1 0% >> internal-timer-start-idle 1 0% >> + and 1 0% > > What do you see if you completely expand the profile? Do you see > line-move-partial anywhere in the profile? That's the only function > where I made significant changes in the offending revisions, so if > it's not high in the profile, I don't know what to think. Here are the top 200 lines of another profile (not identical to the one I posted previously, but similar), which account for 99% of the CPU time. Is this saying that 70% of CPU time is spent in line-move-partial (and 82% in aref)? - call-interactively 7225 30% - next-line 7225 30% - if 7225 30% - if 7225 30% - condition-case 7225 30% - line-move 7225 30% - if 7225 30% - if 7225 30% - if 5398 22% - prog1 5398 22% - let 5397 22% - default-line-height 5397 22% - let 5397 22% - default-font-height 5397 22% - cond 5397 22% aref 5396 22% display-multi-font 1 0% - line-move-visual 1 0% - let 1 0% - if 1 0% - let 1 0% - posn-at-point 1 0% eval 1 0% - and 1827 7% - line-move-partial 1827 7% - if 1827 7% - let* 1827 7% - if 1801 7% - progn 1801 7% - if 1799 7% let 1795 7% if 3 0% and 1 0% - setq 2 0% or 2 0% - default-line-height 21 0% - let 21 0% - if 21 0% or 20 0% display-graphic-p 1 0% - window-screen-lines 5 0% - let 5 0% - default-line-height 3 0% let 3 0% - / 2 0% * 2 0% - next-line 6340 26% - if 6340 26% - if 6340 26% - condition-case 6340 26% - line-move 6340 26% - if 6340 26% - if 6340 26% - and 6247 25% - line-move-partial 6247 25% - if 6247 25% - let* 6247 25% - default-line-height 5351 22% - let 5351 22% - default-font-height 5350 22% - cond 5350 22% aref 5348 22% display-multi-font 2 0% - if 1 0% - display-graphic-p 1 0% framep-on-display 1 0% - if 891 3% - progn 891 3% - setq 888 3% - or 888 3% let 888 3% - if 3 0% - let 3 0% setq 2 0% pos-visible-in-win 1 0% - window-screen-lines 5 0% - let 5 0% - default-line-height 5 0% - let 5 0% if 4 0% default-font-heigh 1 0% - if 93 0% - prog1 93 0% - line-move-visual 89 0% - let 89 0% - or 89 0% - and 89 0% - or 89 0% - and 89 0% >= 89 0% - let 4 0% - default-line-height 4 0% - let 4 0% - default-font-height 4 0% - cond 4 0% - aref 2 0% font-info 2 0% - display-multi-font-p 2 0% framep-on-display 2 0% - if 5387 22% - condition-case 5344 22% - line-move 5344 22% - if 5344 22% - if 5344 22% - and 5342 22% - line-move-partial 5342 22% - if 5342 22% - let* 5342 22% - window-screen-lines 5311 22% - let 5311 22% - default-line-height 5311 22% - let 5311 22% - default-font-height 5311 22% - cond 5311 22% aref 5310 22% display-multi-font 1 0% - if 31 0% - progn 31 0% - if 23 0% - let 23 0% - pos-visible-in-window- 23 0% - eval 23 0% if 21 0% unless 1 0% mode-line-eol-desc 1 0% - setq 6 0% - or 6 0% - let 6 0% - posn-at-point 4 0% eval 3 0% file-remote-p 1 0% - if 2 0% cdr 2 0% - cond 2 0% - and 2 0% - or 2 0% - < 2 0% setq 2 0% - if 2 0% - prog1 2 0% - line-move-visual 2 0% - let 2 0% - or 2 0% - and 2 0% - or 2 0% - and 2 0% - >= 2 0% - vertical-motion 2 0% jit-lock-function 2 0% - if 43 0% - condition-case 43 0% - line-move 43 0% - if 43 0% - if 43 0% - and 43 0% - line-move-partial 43 0% - if 43 0% - let* 43 0% - window-screen-lines 22 0% - let 22 0% - default-line-height 22 0% - let 22 0% - if 21 0% or 20 0% display-graphic-p 1 0% - default-font-height 1 0% cond 1 0% - if 15 0% - progn 15 0% - if 9 0% - let 9 0% - pos-visible-in-windo 9 0% file-remote-p 6 0% eval 3 0% - setq 6 0% - or 6 0% - let 6 0% posn-at-point 5 0% setq 1 0% - default-line-height 6 0% - let 6 0% - default-font-height 6 0% - cond 6 0% - aref 6 0% font-info 6 0% - line-move 4084 16% - if 4084 16% - if 4084 16% - and 4084 16% - line-move-partial 4084 16% - if 4084 16% - let* 4084 16% - if 4084 16% - progn 4084 16% - if 4084 16% - if 4083 16% - and 4083 16% - >= 4083 16% - default-font-height 4083 16% - cond 4083 16% aref 4083 16% >> followed by exactly 175 repetitions of these two lines (I used `M-x >> occur' to make sure they were all identical): >> >> vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0 >> 2 >> >> and nothing else. > > The "py 0" part is very strange. "py" is the vertical coordinate of > point in screen line units. Since this was with C-n, I expect py > never to be less than half the screen height, which is 16. How come > it is zero, i.e. point is in the first line? Can you step through > line-move-partial in Edebug and see what is going on there? If I instrument line-move-partial and type `C-n', I see py = 0 on the first line and it increases by 1 on each subsequent line. I have no idea why *Messages* only showed a value of 0 for py; could it be that the messages were overwritten when the CPU load hit 90%? Is it possible to make Edebug break execution only when that load level occurs? >> > I also asked to try reducing the keyboard auto-repeat rate, and see if >> > that makes any difference. >> >> The default rate in my setup is 25 repeats/s. I lowered it to 15 and >> repeated the above experiment, and the problem again occurs, but starts >> later, around line 300. Then I lowered the repeat rate to 10, which is >> annoyingly slow, and here too the problem occurs, starting around line >> 500. > > This is consistent with the high CPU load you see. But I'd be damned > if I understand what is causing that CPU load, or why it happens with > some fonts, but not others. > > Btw, do you have any local changes in your builds? The builds I tested for my OP were from a branch that mirrors trunk, plus or minus the changes to simple.el from before and after revision 113314; the only changes in the build used for profiling are those you added to simple.el from 113360 to get the messages. Steve Berman ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-11 18:51 ` Stephen Berman @ 2013-07-11 19:16 ` Eli Zaretskii 2013-07-11 20:04 ` Stephen Berman 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2013-07-11 19:16 UTC (permalink / raw) To: Stephen Berman; +Cc: 14838 > From: Stephen Berman <stephen.berman@gmx.net> > Cc: Jan Djärv <jan.h.d@swipnet.se>, 14838@debbugs.gnu.org > Date: Thu, 11 Jul 2013 20:51:42 +0200 > > Here are the top 200 lines of another profile (not identical to the one > I posted previously, but similar), which account for 99% of the CPU > time. Is this saying that 70% of CPU time is spent in line-move-partial > (and 82% in aref)? I don't believe the aref part. I think the real culprit is font-info. Let's conduct an experiment: if you modify default-font-height so that it always just calls frame-char-height, does the problem go away? > >> vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0 > >> 2 > >> > >> and nothing else. > > > > The "py 0" part is very strange. "py" is the vertical coordinate of > > point in screen line units. Since this was with C-n, I expect py > > never to be less than half the screen height, which is 16. How come > > it is zero, i.e. point is in the first line? Can you step through > > line-move-partial in Edebug and see what is going on there? > > If I instrument line-move-partial and type `C-n', I see py = 0 on the > first line and it increases by 1 on each subsequent line. I have no > idea why *Messages* only showed a value of 0 for py; could it be that > the messages were overwritten when the CPU load hit 90%? Could be, since the messages are produced as part of redisplay. Can you show the trace messages from when the CPU is not yet 100% busy, and Emacs can still keep up with scrolling? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-11 19:16 ` Eli Zaretskii @ 2013-07-11 20:04 ` Stephen Berman 2013-07-11 20:25 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Stephen Berman @ 2013-07-11 20:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 14838 On Thu, 11 Jul 2013 22:16:00 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <stephen.berman@gmx.net> >> Cc: Jan Djärv <jan.h.d@swipnet.se>, 14838@debbugs.gnu.org >> Date: Thu, 11 Jul 2013 20:51:42 +0200 >> >> Here are the top 200 lines of another profile (not identical to the one >> I posted previously, but similar), which account for 99% of the CPU >> time. Is this saying that 70% of CPU time is spent in line-move-partial >> (and 82% in aref)? > > I don't believe the aref part. I think the real culprit is font-info. > Let's conduct an experiment: if you modify default-font-height so that > it always just calls frame-char-height, does the problem go away? Yep, that it does. And no trace messages are emitted. So it seems some fonts are sensitive to this distinction and others aren't. What is the crucial difference? >> >> vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0 >> >> 2 >> >> >> >> and nothing else. >> > >> > The "py 0" part is very strange. "py" is the vertical coordinate of >> > point in screen line units. Since this was with C-n, I expect py >> > never to be less than half the screen height, which is 16. How come >> > it is zero, i.e. point is in the first line? Can you step through >> > line-move-partial in Edebug and see what is going on there? >> >> If I instrument line-move-partial and type `C-n', I see py = 0 on the >> first line and it increases by 1 on each subsequent line. I have no >> idea why *Messages* only showed a value of 0 for py; could it be that >> the messages were overwritten when the CPU load hit 90%? > > Could be, since the messages are produced as part of redisplay. > > Can you show the trace messages from when the CPU is not yet 100% > busy, and Emacs can still keep up with scrolling? There are no trace messages while scrolling is normal; only after redisplay stops (with >90% CPU load) and then recovers do the messages appear, and they are all as above, with py=0. I verified this by adding a counter to the messages, and the first message emitted, with count=1, shows py=0, as do all subsequent (none are overwritten). Steve Berman ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-11 20:04 ` Stephen Berman @ 2013-07-11 20:25 ` Eli Zaretskii 2013-07-12 9:48 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2013-07-11 20:25 UTC (permalink / raw) To: Stephen Berman; +Cc: 14838 > From: Stephen Berman <stephen.berman@gmx.net> > Cc: jan.h.d@swipnet.se, 14838@debbugs.gnu.org > Date: Thu, 11 Jul 2013 22:04:07 +0200 > > > I don't believe the aref part. I think the real culprit is font-info. > > Let's conduct an experiment: if you modify default-font-height so that > > it always just calls frame-char-height, does the problem go away? > > Yep, that it does. And no trace messages are emitted. Thanks, I will come up with a change that will refrain from calling font-info unless it's strictly necessary. > So it seems some fonts are sensitive to this distinction and others > aren't. What is the crucial difference? Not sure, but I saw that the implementation of font-info actually opens the font file, so there's probably some non-trivial processing involved in that. And likewise for font-face -- it calls the font back-end. > There are no trace messages while scrolling is normal; only after > redisplay stops (with >90% CPU load) and then recovers do the messages > appear, and they are all as above, with py=0. Ah, OK, now everything is clear. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-11 20:25 ` Eli Zaretskii @ 2013-07-12 9:48 ` Eli Zaretskii 2013-07-12 10:19 ` Stephen Berman 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2013-07-12 9:48 UTC (permalink / raw) To: Stefan Monnier; +Cc: 14838, stephen.berman > Date: Thu, 11 Jul 2013 23:25:05 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 14838@debbugs.gnu.org > > > From: Stephen Berman <stephen.berman@gmx.net> > > Cc: jan.h.d@swipnet.se, 14838@debbugs.gnu.org > > Date: Thu, 11 Jul 2013 22:04:07 +0200 > > > > > I don't believe the aref part. I think the real culprit is font-info. > > > Let's conduct an experiment: if you modify default-font-height so that > > > it always just calls frame-char-height, does the problem go away? > > > > Yep, that it does. And no trace messages are emitted. > > Thanks, I will come up with a change that will refrain from calling > font-info unless it's strictly necessary. I'm unsure what test(s) to use to detect reliably the situation where the font of the default face is different from the frame's default. The two candidates I thought about are: . See if face-remapping-alist is non-nil and includes an association for the 'default' face . Compare (frame-parameter 'font) with (face-font 'default) Regarding the 1st candidate, I'm not sure the condition will always hold whenever the font of the default face was modified in some way. Regarding the 2nd candidate, I'm not sure (frame-parameter 'font) will always return a non-trivial value. Can it return nil, for example? Any other suggestions? Stephen, can you test both of the above in your case? Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-12 9:48 ` Eli Zaretskii @ 2013-07-12 10:19 ` Stephen Berman 2013-07-12 10:35 ` Eli Zaretskii 2013-07-13 7:29 ` Eli Zaretskii 0 siblings, 2 replies; 13+ messages in thread From: Stephen Berman @ 2013-07-12 10:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 14838 On Fri, 12 Jul 2013 12:48:41 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Thu, 11 Jul 2013 23:25:05 +0300 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: 14838@debbugs.gnu.org >> >> > From: Stephen Berman <stephen.berman@gmx.net> >> > Cc: jan.h.d@swipnet.se, 14838@debbugs.gnu.org >> > Date: Thu, 11 Jul 2013 22:04:07 +0200 >> > >> > > I don't believe the aref part. I think the real culprit is font-info. >> > > Let's conduct an experiment: if you modify default-font-height so that >> > > it always just calls frame-char-height, does the problem go away? >> > >> > Yep, that it does. And no trace messages are emitted. >> >> Thanks, I will come up with a change that will refrain from calling >> font-info unless it's strictly necessary. > > I'm unsure what test(s) to use to detect reliably the situation where > the font of the default face is different from the frame's default. > The two candidates I thought about are: > > . See if face-remapping-alist is non-nil and includes an association > for the 'default' face > > . Compare > > (frame-parameter 'font) > > with > > (face-font 'default) > > Regarding the 1st candidate, I'm not sure the condition will always > hold whenever the font of the default face was modified in some way. > > Regarding the 2nd candidate, I'm not sure (frame-parameter 'font) will > always return a non-trivial value. Can it return nil, for example? > > Any other suggestions? > > Stephen, can you test both of the above in your case? With emacs -Q, where the problem with holding down C-n does not happen (when I have no ~/.Xresources file): face-remapping-alist => nil (frame-parameter nil 'font) => "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1" (face-font 'default) => "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1" and after setting the default font to one that does cause the problem: face-remapping-alist => nil (frame-parameter nil 'font) => "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1" (face-font 'default) => "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1" I guess that's not very helpful :-( Steve Berman ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-12 10:19 ` Stephen Berman @ 2013-07-12 10:35 ` Eli Zaretskii 2013-07-13 7:29 ` Eli Zaretskii 1 sibling, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2013-07-12 10:35 UTC (permalink / raw) To: Stephen Berman; +Cc: 14838 > From: Stephen Berman <stephen.berman@gmx.net> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14838@debbugs.gnu.org > Date: Fri, 12 Jul 2013 12:19:44 +0200 > > With emacs -Q, where the problem with holding down C-n does not happen > (when I have no ~/.Xresources file): > > face-remapping-alist => nil > (frame-parameter nil 'font) => > "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1" > (face-font 'default) => > "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1" > > and after setting the default font to one that does cause the problem: > > face-remapping-alist => nil > (frame-parameter nil 'font) => > "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1" > (face-font 'default) => > "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1" > > I guess that's not very helpful :-( No, it actually is very helpful. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-12 10:19 ` Stephen Berman 2013-07-12 10:35 ` Eli Zaretskii @ 2013-07-13 7:29 ` Eli Zaretskii 2013-07-13 13:15 ` Stephen Berman 1 sibling, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2013-07-13 7:29 UTC (permalink / raw) To: Stephen Berman; +Cc: 14838 > From: Stephen Berman <stephen.berman@gmx.net> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14838@debbugs.gnu.org > Date: Fri, 12 Jul 2013 12:19:44 +0200 > > With emacs -Q, where the problem with holding down C-n does not happen > (when I have no ~/.Xresources file): > > face-remapping-alist => nil > (frame-parameter nil 'font) => > "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1" > (face-font 'default) => > "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1" > > and after setting the default font to one that does cause the problem: > > face-remapping-alist => nil > (frame-parameter nil 'font) => > "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1" > (face-font 'default) => > "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1" Please try trunk revision 113410 or later. If the problem with slow scrolling is not solved by it, please tell what did I do wrong in default-font-height. It is supposed not to call font-info in your case. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken 2013-07-13 7:29 ` Eli Zaretskii @ 2013-07-13 13:15 ` Stephen Berman 0 siblings, 0 replies; 13+ messages in thread From: Stephen Berman @ 2013-07-13 13:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 14838-done On Sat, 13 Jul 2013 10:29:55 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >> From: Stephen Berman <stephen.berman@gmx.net> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14838@debbugs.gnu.org >> Date: Fri, 12 Jul 2013 12:19:44 +0200 >> >> With emacs -Q, where the problem with holding down C-n does not happen >> (when I have no ~/.Xresources file): >> >> face-remapping-alist => nil >> (frame-parameter nil 'font) => >> "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1" >> (face-font 'default) => >> "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1" >> >> and after setting the default font to one that does cause the problem: >> >> face-remapping-alist => nil >> (frame-parameter nil 'font) => >> "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1" >> (face-font 'default) => >> "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1" > > Please try trunk revision 113410 or later. If the problem with slow > scrolling is not solved by it, please tell what did I do wrong in > default-font-height. It is supposed not to call font-info in your > case. With that revision the problem is now solved, so I'm closing the bug. FWIW, I don't see it with the ~/.Xresources file now, either (though it remains a mystery why that was apparently also triggering the problem, but one not worth keeping this bug open for). Thanks very much for fixing this. Steve Berman ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-07-13 13:15 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-07-10 21:29 bug#14838: 24.3.50; repeating next-line or previous-line is broken Stephen Berman 2013-07-11 2:51 ` Eli Zaretskii 2013-07-11 10:04 ` Stephen Berman 2013-07-11 15:59 ` Eli Zaretskii 2013-07-11 18:51 ` Stephen Berman 2013-07-11 19:16 ` Eli Zaretskii 2013-07-11 20:04 ` Stephen Berman 2013-07-11 20:25 ` Eli Zaretskii 2013-07-12 9:48 ` Eli Zaretskii 2013-07-12 10:19 ` Stephen Berman 2013-07-12 10:35 ` Eli Zaretskii 2013-07-13 7:29 ` Eli Zaretskii 2013-07-13 13:15 ` Stephen Berman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).