GNU bug report logs -
#77039
31.0.50; Flickering on macOS
Previous Next
Reported by: Aaron Jensen <aaronjensen <at> gmail.com>
Date: Sat, 15 Mar 2025 16:43:01 UTC
Severity: normal
Found in version 31.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77039 in the body.
You can then email your comments to 77039 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 15 Mar 2025 16:43:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Aaron Jensen <aaronjensen <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 15 Mar 2025 16:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I have been using Emacs 31 since the version was increased on master. In
the last few monthns I have noticed that there is occasional flickering
where the text will not render and the background will be visible. This
only happens in a part of the window and not the entire window. It seems
to get worse the longer Emacs is open and it seems to only occur in
certain buffers or windows. I cannot consistently reproduce it and
sometimes it takes hours of Emacs being open for it to start happening
so it's challenging to bisect.
I don't know if there have been any changes to the rendering code
recently that could potentially cause this. I'm wondering about the
recent child frame changes to make them compatible with the terminal. I
make heavy use of child frames for text completions and other things. Is
it possible that that is related? I don't think there have been many
macOS specific changes recently.
I'll send more information as I get it, but I wanted to report this
in case anyone had any ideas.
In GNU Emacs 31.0.50 (build 2, aarch64-apple-darwin24.3.0, NS
appkit-2575.40 Version 15.3.2 (Build 24D81)) of 2025-03-15 built on
Aarons-MacBook-Pro-3.local
Repository revision: 3860562a715b8ba7b727f7831e06ce5a0e676784
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2575
System Description: macOS 15.3.2
Configured using:
'configure --with-ns --with-native-compilation --with-modules
--without-dbus --without-webp --with-xml2 --with-gnutls
--disable-ns-self-contained'
Configured features:
ACL GLIB GNUTLS LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE NS
PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER XIM
ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Magit
Minor modes in effect:
xterm-mouse-mode: t
pdf-occur-global-minor-mode: t
eval-sexp-fu-flash-mode: t
magit-delta-mode: t
global-flycheck-mode: t
consult-notes-denote-mode: t
denote-rename-buffer-mode: t
denote-menu-bar-mode: t
windmove-mode: t
corfu-prescient-mode: t
corfu-history-mode: t
which-key-posframe-mode: t
which-key-mode: t
global-anzu-mode: t
anzu-mode: t
global-evil-mc-mode: t
global-evil-surround-mode: t
evil-surround-mode: t
global-git-commit-mode: t
global-auto-revert-mode: t
treemacs-filewatch-mode: t
treemacs-follow-mode: t
treemacs-git-mode: t
treemacs-fringe-indicator-mode: t
ns-auto-titlebar-mode: t
recentf-mode: t
repeat-mode: t
gcmh-mode: t
undo-fu-session-global-mode: t
ws-butler-global-mode: t
save-place-mode: t
tabspaces-mode: t
savehist-mode: t
delete-selection-mode: t
yas-global-mode: t
yas-minor-mode: t
vertico-prescient-mode: t
prescient-persist-mode: t
vertico-mouse-mode: t
vertico-mode: t
mini-frame-mode: t
better-jumper-mode: t
modern-tab-bar-mode: t
+popup-mode: t
evil-mode: t
evil-local-mode: t
server-mode: t
leader-key-leader-override-mode: t
global-leader-key-leader-override-mode: t
elpaca-use-package-mode: t
override-global-mode: t
global-display-line-numbers-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tab-bar-history-mode: t
tab-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
window-divider-mode: t
minibuffer-regexp-mode: t
buffer-read-only: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/Users/aaronjensen/.emacs.d/elpaca/builds/lispy/elpa hides /Users/aaronjensen/.emacs.d/elpaca/builds/ivy/elpa
/Users/aaronjensen/.emacs.d/elpaca/builds/transient/transient hides /Users/aaronjensen/Source/emacs/lisp/transient
Features:
(shadow sort mail-extr emacsbug lisp-mnt tramp-cmds vc-hg vc-bzr vc-src
vc-sccs vc-svn vc-cvs vc-rcs log-view bug-reference org-capture
evil-collection-dired typescript-ts-mode lsp-diagnostics lsp-modeline
lsp-icons lsp-lens lsp-zig lsp-yang lsp-yaml lsp-xml lsp-wgsl lsp-volar
lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v
lsp-typespec lsp-typeprof lsp-ttcn3 lsp-ts-query lsp-trunk lsp-toml
lsp-tilt lsp-tex lsp-terraform lsp-svelte lsp-steep lsp-sqls lsp-sql
lsp-sorbet lsp-solidity lsp-solargraph lsp-semgrep lsp-rust lsp-ruff
lsp-ruby-syntax-tree lsp-ruby-lsp lsp-rubocop lsp-roslyn lsp-roc lsp-rf
lsp-remark lsp-racket lsp-r lsp-qml lsp-pylsp lsp-pyls lsp-pwsh
lsp-purescript lsp-pls lsp-php lsp-perlnavigator lsp-perl lsp-openscad
lsp-ocaml lsp-nushell lsp-nix lsp-nim lsp-nginx lsp-nextflow lsp-move
lsp-mojo lsp-mint lsp-meson lsp-mdx lsp-matlab lsp-marksman lsp-markdown
lsp-magik lsp-fennel lsp-lua lsp-lisp lsp-kubernetes-helm lsp-kotlin
lsp-json lsp-jq lsp-javascript lsp-idris lsp-haxe lsp-hack lsp-groovy
lsp-graphql lsp-golangci-lint lsp-glsl lsp-gleam lsp-gdscript lsp-fsharp
lsp-futhark lsp-fortran lsp-eslint lsp-erlang lsp-emmet lsp-elm
lsp-elixir lsp-earthly lsp-dockerfile lsp-dhall lsp-d lsp-cypher
lsp-cucumber lsp-copilot lsp-css lsp-c3 lsp-csharp lsp-crystal lsp-credo
lsp-cobol lsp-cmake lsp-clojure lsp-clangd lsp-bufls lsp-go
lsp-completion lsp-beancount lsp-bash lsp-awk lsp-autotools lsp-astro
lsp-asm lsp-ansible lsp-angular lsp-ada lsp-semantic-tokens
lsp-actionscript dabbrev elec-pair tab-line popup-mode-core diary-lib
diary-loaddefs org-indent oc-basic ol-eww ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls
dig gnus-sum gnus-group gnus-undo gnus-start gnus-dbus dbus gnus-cloud
nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range
gnus-win ol-docview doc-view ol-bibtex bibtex ol-bbdb ol-w3m ol-doi
org-link-doi magit-extras flyspell ispell visual-wrap vertico-directory
xt-mouse swiper ivy ivy-faces ivy-overlay colir iedit iedit-lib
hide-mode-line goto-chg cfrs elysium gptel-ollama gptel gptel-openai
copy-as-format tabify evil-collection-pdf pdf-history pdf-occur ibuf-ext
evil-collection-ibuffer ibuffer ibuffer-loaddefs tablist tablist-filter
semantic/wisent/comp semantic/wisent semantic/wisent/wisent
semantic/util-modes semantic/util semantic semantic/tag cedet
pdf-isearch let-alist pdf-misc pdf-loader pdf-tools pdf-view jka-compr
pdf-cache pdf-info tq pdf-util pdf-macs image-mode exif
evil-collection-restclient restclient dumb-jump popup haml-mode css-mode
eww vtable url-queue shr pixel-fill kinsoku url-file svg xml mm-url gnus
nnheader range emmet-mode terraform-mode hcl-mode dockerfile-mode
yaml-mode json-mode json-snatcher js c-ts-common cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine grip-mode
lua-mode ruby-refactor bundler inf-ruby ruby-mode evil-ruby-text-objects
sotlisp skeleton elisp-def ert lispyville lispy hydra lispy-inline etags
fileloop lispy-tags zoutline eros eval-sexp-fu web-mode ripgrep-capf
git-link consult-git-commit evil-collection-git-timemachine
git-timemachine magit-delta prettier editorconfig editorconfig-core
editorconfig-core-handle editorconfig-fnmatch nvm iter2 lsp-ui
lsp-ui-flycheck lsp-ui-doc goto-addr lsp-ui-imenu lsp-ui-peek
lsp-ui-sideline flycheck lsp-ui-util lsp-mode lsp-protocol spinner
network-stream markdown-mode lv ewoc consult-notes-denote consult-notes
denote-rename-buffer denote imenu-list hideshow org-superstar
org-pandoc-import gnuplot org-journal org-crypt cal-iso orgonomic
org-drill persist org-appear org-mac-link org-goto embark-org
org-download url-http url-auth url-gw nsm async evil-org-agenda evil-org
ob-shell ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util
rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex
ox-icalendar org-agenda ox-ascii ox-gfm ox-md ox-html table ox-publish
ox org-attach org-element org-persist org-id org-refile org-element-ast
avl-tree generator org-tempo tempo org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src sh-script smie treesit executable
ob-comint org-pcomplete org-list org-footnote org-faces org-entities
noutline outline org-version ob-emacs-lisp ob-core ob-eval org-cycle
org-table ol org-fold org-fold-core org-keys oc org-loaddefs cal-menu
calendar cal-loaddefs org-compat org-macs evil-terminal-cursor-changer
ace-window buffer-move windmove rotate embark-consult embark ffap
consult cape corfu-prescient corfu-history evil-collection-corfu corfu
which-key-posframe evil-collection-which-key which-key evil-anzu anzu
titlecase titlecase-data wgrep grep avy form-feed dtrt-indent evil-mc
evil-mc-command-execute evil-mc-command-record evil-mc-cursor-make
evil-mc-region evil-mc-cursor-state evil-mc-undo evil-mc-vars
evil-mc-known-commands evil-mc-common evil-numbers speeddating
evil-matchit evil-matchit-evil-setup evil-matchit-sdk semantic/lex
semantic/fw mode-local evil-nerd-commenter evil-nerd-commenter-operator
evil-nerd-commenter-sdk sgml-mode facemenu dom evil-visualstar
evil-surround evil-collection-vundo vundo evil-collection-ztree ztree
ztree-diff ztree-diff-model ztree-dir ztree-view ztree-protocol
ztree-util dwim-shell-commands proced dwim-shell-command view
evil-collection-magit treemacs-magit magit-bookmark magit-submodule
magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull
magit-fetch magit-clone magit-remote magit-commit magit-sequence
magit-notes magit-worktree magit-tag magit-merge magit-branch
magit-reset magit-files magit-refs magit-status magit package
url-handlers magit-repos magit-apply magit-wip magit-log magit-diff
smerge-mode diff git-commit log-edit message sendmail yank-media puny
rfc822 mml mml-sec epa epg rfc6068 epg-config gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log magit-core magit-autorevert autorevert magit-margin
magit-transient magit-process with-editor magit-mode browse-url
benchmark magit-git magit-base magit-section cursor-sensor crm llama
treemacs-evil treemacs-tab-bar treemacs treemacs-header-line
treemacs-compatibility treemacs-mode treemacs-bookmarks treemacs-tags
evil-collection-xref xref treemacs-interface treemacs-persistence
treemacs-filewatch-mode filenotify treemacs-follow-mode
treemacs-rendering treemacs-annotations treemacs-async
treemacs-workspaces treemacs-dom treemacs-visuals
treemacs-fringe-indicator pulse treemacs-faces treemacs-icons
treemacs-scope treemacs-themes treemacs-core-utils pfuture inline
hl-line ht treemacs-logging treemacs-customization treemacs-macros
all-the-icons all-the-icons-faces data-material data-weathericons
data-octicons data-fileicons data-faicons data-alltheicons rainbow-mode
xterm-color posframe ns-auto-titlebar envrc inheritenv
evil-collection-helpful helpful cc-langs cc-vars cc-defs trace cl-print
evil-collection-edebug edebug evil-collection-debug debug backtrace
info-look info f help-fns radix-tree elisp-refs s dired-subtree
dired-hacks-utils dired-aux dash recentf tree-widget repeat gcmh
undo-fu-session ws-butler saveplace tabspaces dired-x vc savehist delsel
yasnippet vertico-prescient prescient char-fold vertico-mouse vertico
mini-frame better-jumper advice popup-mode-hacks aidermacs
aidermacs-models aidermacs-backends aidermacs-backend-vterm
evil-collection-vterm vterm bookmark color term ehelp find-func
vterm-module term/xterm xterm aidermacs-backend-comint tramp trampver
tramp-integration tramp-message tramp-compat xdg shell pcomplete
parse-time iso8601 tramp-loaddefs which-func imenu vc-git diff-mode
track-changes files-x vc-dispatcher evil-collection-ediff ediff
ediff-merg ediff-mult ediff-wind ediff-diff ediff-help ediff-init
ediff-util dired dired-loaddefs transient format-spec orderless
modern-tab-bar popup-mode popup-mode-settings evil-collection-elpaca
evil-collection annalist evil-little-word cus-edit cus-start cus-load
wid-edit pp evil evil-integration evil-maps evil-commands reveal
evil-jumps evil-command-window evil-types evil-search evil-ex
evil-macros evil-repeat evil-states evil-core project evil-common
thingatpt rect evil-vars memoize nano-modeline nano-theme face-remap
nano-theme-support disp-table gcmh-autoloads elysium-autoloads
gptel-autoloads aidermacs-autoloads copy-as-format-autoloads
pdf-tools-autoloads tablist-autoloads restclient-autoloads
vterm-autoloads dumb-jump-autoloads popup-autoloads haml-mode-autoloads
emmet-mode-autoloads terraform-mode-autoloads hcl-mode-autoloads
dockerfile-mode-autoloads yaml-mode-autoloads json-mode-autoloads
json-snatcher-autoloads grip-mode-autoloads lua-mode-autoloads
bundler-autoloads inf-ruby-autoloads ruby-refactor-autoloads
evil-ruby-text-objects-autoloads sotlisp-autoloads elisp-def-autoloads
lispyville-autoloads lispy-autoloads iedit-autoloads swiper-autoloads
ivy-autoloads zoutline-autoloads eros-autoloads eval-sexp-fu-autoloads
web-mode-autoloads ripgrep-capf-autoloads git-link-autoloads
consult-git-commit-autoloads git-timemachine-autoloads
magit-delta-autoloads xterm-color-autoloads prettier-autoloads
iter2-autoloads nvm-autoloads flycheck-autoloads lsp-ui-autoloads
lsp-mode-autoloads spinner-autoloads markdown-mode-autoloads
consult-notes-autoloads denote-autoloads imenu-list-autoloads
org-superstar-autoloads ox-gfm-autoloads org-pandoc-import-autoloads
gnuplot-autoloads org-download-autoloads async-autoloads
org-journal-autoloads orgonomic-autoloads org-drill-autoloads
persist-autoloads org-appear-autoloads org-mac-link-autoloads
evil-org-autoloads evil-terminal-cursor-changer-autoloads
better-jumper-autoloads buffer-move-autoloads rotate-autoloads
mini-frame-autoloads embark-consult-autoloads embark-autoloads
consult-autoloads orderless-autoloads cape-autoloads
corfu-prescient-autoloads corfu-autoloads vertico-prescient-autoloads
vertico-autoloads prescient-autoloads tabspaces-autoloads
modern-tab-bar-autoloads which-key-posframe-autoloads
popup-mode-autoloads hide-mode-line-autoloads evil-anzu-autoloads
anzu-autoloads titlecase-autoloads wgrep-autoloads yasnippet-autoloads
form-feed-autoloads dtrt-indent-autoloads ws-butler-autoloads
evil-collection-autoloads annalist-autoloads evil-mc-autoloads
evil-numbers-autoloads speeddating-autoloads evil-little-word-autoloads
evil-matchit-autoloads evil-nerd-commenter-autoloads
evil-visualstar-autoloads evil-surround-autoloads vundo-autoloads
undo-fu-session-autoloads ztree-autoloads dwim-shell-command-autoloads
treemacs-tab-bar-autoloads treemacs-magit-autoloads magit-autoloads
magit-section-autoloads llama-autoloads transient-autoloads
with-editor-autoloads treemacs-evil-autoloads evil-autoloads
goto-chg-autoloads treemacs-autoloads ace-window-autoloads avy-autoloads
pfuture-autoloads hydra-autoloads lv-autoloads ht-autoloads
cfrs-autoloads all-the-icons-autoloads rainbow-mode-autoloads
posframe-autoloads ns-auto-titlebar-autoloads nano-modeline-autoloads
nano-theme-autoloads memoize-autoloads envrc-autoloads
inheritenv-autoloads helpful-autoloads f-autoloads elisp-refs-autoloads
s-autoloads dired-subtree-autoloads dired-hacks-utils-autoloads
dash-autoloads server pcase edmacro kmacro compdef derived
compdef-autoloads leader-key bind-map leader-key-autoloads
bind-map-autoloads no-littering compat no-littering-autoloads
elpaca-use-package use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core elpaca-use-package-autoloads compile
text-property-search comint ansi-osc ansi-color ring time-date comp-run
literate-config literate-config-autoloads elpaca-log elpaca-ui
elpaca-menu-elpa elpaca-menu-melpa url url-proxy url-privacy url-expand
url-methods url-history url-cookie generate-lisp-file url-domsuf
url-util url-parse auth-source eieio eieio-core cl-macs password-cache
json map byte-opt url-vars mailcap elpaca-menu-org elpaca elpaca-process
elpaca-autoloads comp cl-seq comp-cstr comp-common warnings subr-x rx gv
bytecomp byte-compile cl-extra help-mode icons cl-loaddefs cl-lib
display-line-numbers rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process tty-child-frames native-compile emacs)
Memory information:
((conses 16 2238502 3433019) (symbols 48 87339 26) (strings 32 653723 387319)
(string-bytes 1 16855963) (vectors 16 290916) (vector-slots 8 3770891 910650)
(floats 8 3361 4370) (intervals 56 25266 4815) (buffers 992 74))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 15 Mar 2025 16:50:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here's a video clip: https://share.cleanshot.com/x8zWLgYf
It seems to happen more often when there is significant load. In this case,
I was running an 8 worker web server in a vterm in Emacs and a set of 8
parallel UI tests against it. The server was printing log messages at a
rapid rate, but that vterm buffer was not visible.
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 02:20:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Adding Gerd Möllmann.
The flicker appears to have been introduced by the work done in 414de92a562
Initial child frames based on master (Mon Oct 21 18:32:04 2024 +0200, 5
months ago) <Gerd Möllmann>
It's a fairly large change set, so I don't know yet what might be causing
it. I can reproduce it fairly consistently using my own setup, but I don't
know how to narrow it down to something from Emacs -Q because it appears to
be related to CPU utilization and/or rapid updating of buffers that are not
currently visible.
Aaron
On Sat, Mar 15, 2025 at 9:49 AM, Aaron Jensen <aaronjensen <at> gmail.com> wrote:
> Here's a video clip: https://share.cleanshot.com/x8zWLgYf
>
> It seems to happen more often when there is significant load. In this
> case, I was running an 8 worker web server in a vterm in Emacs and a set of
> 8 parallel UI tests against it. The server was printing log messages at a
> rapid rate, but that vterm buffer was not visible.
>
>
> Aaron
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 04:44:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Aaron Jensen <aaronjensen <at> gmail.com> writes:
> Adding Gerd Möllmann.
>
> The flicker appears to have been introduced by the work done in 414de92a562
>
> Initial child frames based on master (Mon Oct 21 18:32:04 2024 +0200, 5 months ago) <Gerd Möllmann>
>
> It's a fairly large change set, so I don't know yet what might be causing it. I can reproduce it fairly consistently
> using my own setup, but I don't know how to narrow it down to something from Emacs -Q because it appears to be related to
> CPU utilization and/or rapid updating of buffers that are not currently visible.
>
> Aaron
>
> On Sat, Mar 15, 2025 at 9:49 AM, Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> Here's a video clip: https://share.cleanshot.com/x8zWLgYf
>
> It seems to happen more often when there is significant load. In this case, I was running an 8 worker web server in a
> vterm in Emacs and a set of 8 parallel UI tests against it. The server was printing log messages at a rapid rate, but
> that vterm buffer was not visible.
>
> Aaron
I'm afraid I have not the slightest idea.
414de92a562 concerns only ttys, AFAICT. I've looked through the commit
again right now. The changes to NS code directly are only trivial ones
(1 -> true, 0 -> false etc.). So it would have to be something in
redisplay_internal or something similar, in code not specific to NS that
is used on all window systems, and I don't see a change there that could
cause something with the symptoms you describe.
Adding Alan Third in CC. Maybe he has an idea.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 06:05:05 GMT)
Full text and
rfc822 format available.
Message #17 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Mar 15, 2025 at 9:43 PM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> Adding Gerd Möllmann.
>
> The flicker appears to have been introduced by the work done in
> 414de92a562
>
> Initial child frames based on master (Mon Oct 21 18:32:04 2024 +0200, 5
> months ago) <Gerd Möllmann>
>
> It's a fairly large change set, so I don't know yet what might be causing
> it. I can reproduce it fairly consistently using my own setup, but I don't
> know how to narrow it down to something from Emacs -Q because it appears to
> be related to CPU utilization and/or rapid updating of buffers that are not
> currently visible.
>
> Aaron
>
> On Sat, Mar 15, 2025 at 9:49 AM, Aaron Jensen <aaronjensen <at> gmail.com>
> wrote:
>
> Here's a video clip: https://share.cleanshot.com/x8zWLgYf
>
> It seems to happen more often when there is significant load. In this
> case, I was running an 8 worker web server in a vterm in Emacs and a set of
> 8 parallel UI tests against it. The server was printing log messages at a
> rapid rate, but that vterm buffer was not visible.
>
> Aaron
>
> I'm afraid I have not the slightest idea.
>
> 414de92a562 concerns only ttys, AFAICT. I've looked through the commit
> again right now. The changes to NS code directly are only trivial ones
> (1 -> true, 0 -> false etc.). So it would have to be something in
> redisplay_internal or something similar, in code not specific to NS that is
> used on all window systems, and I don't see a change there that could cause
> something with the symptoms you describe.
>
> Adding Alan Third in CC. Maybe he has an idea.
>
I'll try and eliminate aspects of the patch as best as I can. If this is,
in fact, a macOS only issue, then it may be that the particular method of
drawing the windows in macOS is susceptible to some change that was made
here. No idea what it could be, either. I do see that the NS-specific
changes appear to be innocuous.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 06:24:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> Cc: gerd <at> gnu.org
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sun, 16 Mar 2025 02:19:32 +0000
>
> Adding Gerd Möllmann.
Sub-optimal address; fixed with this message.
> The flicker appears to have been introduced by the work done in 414de92a562
>
> Initial child frames based on master (Mon Oct 21 18:32:04 2024 +0200, 5 months ago) <Gerd Möllmann>
>
> It's a fairly large change set, so I don't know yet what might be causing it. I can reproduce it fairly consistently
> using my own setup, but I don't know how to narrow it down to something from Emacs -Q because it appears
> to be related to CPU utilization and/or rapid updating of buffers that are not currently visible.
>
> Aaron
>
> On Sat, Mar 15, 2025 at 9:49 AM, Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> Here's a video clip: https://share.cleanshot.com/x8zWLgYf
>
> It seems to happen more often when there is significant load. In this case, I was running an 8 worker
> web server in a vterm in Emacs and a set of 8 parallel UI tests against it. The server was printing log
> messages at a rapid rate, but that vterm buffer was not visible.
>
> Aaron
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 06:56:03 GMT)
Full text and
rfc822 format available.
Message #23 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: gerd <at> gnu.org
>> From: Aaron Jensen <aaronjensen <at> gmail.com>
>> Date: Sun, 16 Mar 2025 02:19:32 +0000
>>
>> Adding Gerd Möllmann.
>
> Sub-optimal address; fixed with this message.
Thanks. This was a case where I actually got Aaron's mail.
@Aaron: gerd <at> gnu.org doesn't work anymore, with 2 exceptions so far, one
being your mail.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 07:50:04 GMT)
Full text and
rfc822 format available.
Message #26 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Mar 15, 2025 at 11:55 PM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Cc: gerd <at> gnu.org
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sun, 16 Mar 2025 02:19:32 +0000
>
> Adding Gerd Möllmann.
>
> Sub-optimal address; fixed with this message.
>
> Thanks. This was a case where I actually got Aaron's mail.
>
> @Aaron: gerd <at> gnu.org doesn't work anymore, with 2 exceptions so far, one
> being your mail.
>
Understood, thanks.
Do you by chance have a version of 414de92a562 that is split into multiple,
sequential commits? The area of most suspicion to me is the rewrite of
update_frame. It's the most significant change, and without going through
it part by part, I can't tell if the non-try changes are mere
refactoring or if they actually have behavioral change.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 07:56:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
One other thing, it may be related to tab-bar mode. It seems to be
connected to when I switch tabs — one tab has a vterm buffer scrolling
output and the other just has a grep output, for example. If I don't get
the flicker in the grep output, I can switch back and forth between the two
tabs a couple times and I'll start to get it.
Aaron
On Sat, Mar 15, 2025 at 11:03 PM, Aaron Jensen <aaronjensen <at> gmail.com>
wrote:
> On Sat, Mar 15, 2025 at 9:43 PM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
> wrote:
>
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> Adding Gerd Möllmann.
>
> The flicker appears to have been introduced by the work done in
> 414de92a562
>
> Initial child frames based on master (Mon Oct 21 18:32:04 2024 +0200, 5
> months ago) <Gerd Möllmann>
>
> It's a fairly large change set, so I don't know yet what might be causing
> it. I can reproduce it fairly consistently using my own setup, but I don't
> know how to narrow it down to something from Emacs -Q because it appears to
> be related to CPU utilization and/or rapid updating of buffers that are not
> currently visible.
>
> Aaron
>
> On Sat, Mar 15, 2025 at 9:49 AM, Aaron Jensen <aaronjensen <at> gmail.com>
> wrote:
>
> Here's a video clip: https://share.cleanshot.com/x8zWLgYf
>
> It seems to happen more often when there is significant load. In this
> case, I was running an 8 worker web server in a vterm in Emacs and a set of
> 8 parallel UI tests against it. The server was printing log messages at a
> rapid rate, but that vterm buffer was not visible.
>
> Aaron
>
> I'm afraid I have not the slightest idea.
>
> 414de92a562 concerns only ttys, AFAICT. I've looked through the commit
> again right now. The changes to NS code directly are only trivial ones
> (1 -> true, 0 -> false etc.). So it would have to be something in
> redisplay_internal or something similar, in code not specific to NS that is
> used on all window systems, and I don't see a change there that could cause
> something with the symptoms you describe.
>
> Adding Alan Third in CC. Maybe he has an idea.
>
>
> I'll try and eliminate aspects of the patch as best as I can. If this is,
> in fact, a macOS only issue, then it may be that the particular method of
> drawing the windows in macOS is susceptible to some change that was made
> here. No idea what it could be, either. I do see that the NS-specific
> changes appear to be innocuous.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 08:57:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Aaron Jensen <aaronjensen <at> gmail.com> writes:
> Do you by chance have a version of 414de92a562 that is split into
> multiple, sequential commits? The area of most suspicion to me is the
> rewrite of update_frame.
Kind of unlikely, but who knows. Update_frame splits into 3 branches,
one for window-system frames, one for tty frames, and one for the
initial frame. NS uses the update_window_frame, which shouldn't have
changed.
> It's the most significant change, and without going through it part by
> part, I can't tell if the non-try changes are mere refactoring or if
> they actually have behavioral change.
There is the branch scratch/tty-child-frames, which has a few commits,
but that's it, I'm afraid. I did the original development in my fork of
Emacs on Github, and deleted the branch, when things landed in master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 09:01:04 GMT)
Full text and
rfc822 format available.
Message #35 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Aaron Jensen <aaronjensen <at> gmail.com> writes:
> One other thing, it may be related to tab-bar mode. It seems to be
> connected to when I switch tabs — one tab has a vterm buffer scrolling
> output and the other just has a grep output, for example. If I don't
> get the flicker in the grep output, I can switch back and forth
> between the two tabs a couple times and I'll start to get it.
Doesn't ring a bell, I'm afraid. Tab bar, AFAIU it, is "just playing with
window configurations". Why that would lead to flickering, I can't
imagine ATM.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 11:50:04 GMT)
Full text and
rfc822 format available.
Message #38 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 16, 2025 at 2:05 AM Aaron Jensen <aaronjensen <at> gmail.com> wrote:
> On Sat, Mar 15, 2025 at 9:43 PM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
> wrote:
>
>> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>>
>> Adding Gerd Möllmann.
>>
>> The flicker appears to have been introduced by the work done in
>> 414de92a562
>>
>> Initial child frames based on master (Mon Oct 21 18:32:04 2024 +0200, 5
>> months ago) <Gerd Möllmann>
>>
>> It's a fairly large change set, so I don't know yet what might be causing
>> it. I can reproduce it fairly consistently using my own setup, but I don't
>> know how to narrow it down to something from Emacs -Q because it appears to
>> be related to CPU utilization and/or rapid updating of buffers that are not
>> currently visible.
>>
>> Aaron
>>
>> On Sat, Mar 15, 2025 at 9:49 AM, Aaron Jensen <aaronjensen <at> gmail.com>
>> wrote:
>>
>> Here's a video clip: https://share.cleanshot.com/x8zWLgYf
>>
>> It seems to happen more often when there is significant load. In this
>> case, I was running an 8 worker web server in a vterm in Emacs and a set of
>> 8 parallel UI tests against it. The server was printing log messages at a
>> rapid rate, but that vterm buffer was not visible.
>>
>> Aaron
>>
>> I'm afraid I have not the slightest idea.
>>
>> 414de92a562 concerns only ttys, AFAICT. I've looked through the commit
>> again right now. The changes to NS code directly are only trivial ones
>> (1 -> true, 0 -> false etc.). So it would have to be something in
>> redisplay_internal or something similar, in code not specific to NS that is
>> used on all window systems, and I don't see a change there that could cause
>> something with the symptoms you describe.
>>
>> Adding Alan Third in CC. Maybe he has an idea.
>>
>
> I'll try and eliminate aspects of the patch as best as I can. If this is,
> in fact, a macOS only issue, then it may be that the particular method of
> drawing the windows in macOS is susceptible to some change that was made
> here. No idea what it could be, either. I do see that the NS-specific
> changes appear to be innocuous.
>
What is your frame-parameter inhibit-double-buffering set to? Have you
tried flip-flopping it to see if that has an impact?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 16:44:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 16, 2025 at 4:49 AM, Ship Mints <shipmints <at> gmail.com> wrote:
> On Sun, Mar 16, 2025 at 2:05 AM Aaron Jensen <aaronjensen <at> gmail.com>
> wrote:
>
>> On Sat, Mar 15, 2025 at 9:43 PM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> wrote:
>>
>>> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>>>
>>> Adding Gerd Möllmann.
>>>
>>> The flicker appears to have been introduced by the work done in
>>> 414de92a562
>>>
>>> Initial child frames based on master (Mon Oct 21 18:32:04 2024 +0200, 5
>>> months ago) <Gerd Möllmann>
>>>
>>> It's a fairly large change set, so I don't know yet what might be
>>> causing it. I can reproduce it fairly consistently using my own setup, but
>>> I don't know how to narrow it down to something from Emacs -Q because it
>>> appears to be related to CPU utilization and/or rapid updating of buffers
>>> that are not currently visible.
>>>
>>> Aaron
>>>
>>> On Sat, Mar 15, 2025 at 9:49 AM, Aaron Jensen <aaronjensen <at> gmail.com>
>>> wrote:
>>>
>>> Here's a video clip: https://share.cleanshot.com/x8zWLgYf
>>>
>>> It seems to happen more often when there is significant load. In this
>>> case, I was running an 8 worker web server in a vterm in Emacs and a set of
>>> 8 parallel UI tests against it. The server was printing log messages at a
>>> rapid rate, but that vterm buffer was not visible.
>>>
>>> Aaron
>>>
>>> I'm afraid I have not the slightest idea.
>>>
>>> 414de92a562 concerns only ttys, AFAICT. I've looked through the commit
>>> again right now. The changes to NS code directly are only trivial ones
>>> (1 -> true, 0 -> false etc.). So it would have to be something in
>>> redisplay_internal or something similar, in code not specific to NS that is
>>> used on all window systems, and I don't see a change there that could cause
>>> something with the symptoms you describe.
>>>
>>> Adding Alan Third in CC. Maybe he has an idea.
>>>
>>
>> I'll try and eliminate aspects of the patch as best as I can. If this is,
>> in fact, a macOS only issue, then it may be that the particular method of
>> drawing the windows in macOS is susceptible to some change that was made
>> here. No idea what it could be, either. I do see that the NS-specific
>> changes appear to be innocuous.
>>
>
> What is your frame-parameter inhibit-double-buffering set to? Have you
> tried flip-flopping it to see if that has an impact?
>
I usually have it set to true, but yes, changing it was the first thing I
tried. It seems to reduce the overall impact of the flicker (at least when
I tried it again just now), but it still happens even when double buffering
is enabled.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 17:16:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I've narrowed it down to the addition to frame in the glyph comparison. As
far as I can tell, the attached patch removes the flickering for me. I saw
the cursor blink once, but I couldn't reproduce that and I couldn't get it
to do it again.
The patch is not suitable for applying to master as it certainly breaks
something int he tty child frame code, but hopefully it gives you an idea
of what the problem might be. I'm going to experiment with accounting for
the NULL frame in the space glyph and see if that helps.
Aaron
On Sun, Mar 16, 2025 at 2:00 AM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> One other thing, it may be related to tab-bar mode. It seems to be
> connected to when I switch tabs — one tab has a vterm buffer scrolling
> output and the other just has a grep output, for example. If I don't get
> the flicker in the grep output, I can switch back and forth between the two
> tabs a couple times and I'll start to get it.
>
> Doesn't ring a bell, I'm afraid. Tab bar, AFAIU it, is "just playing with
> window configurations". Why that would lead to flickering, I can't imagine
> ATM.
>
[Message part 2 (text/html, inline)]
[0001-Eliminate-flicker-on-macOS-do-not-apply.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 17:20:03 GMT)
Full text and
rfc822 format available.
Message #47 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 16, 2025 at 10:15 AM, Aaron Jensen <aaronjensen <at> gmail.com>
wrote:
> Hi,
>
> I've narrowed it down to the addition to frame in the glyph comparison. As
> far as I can tell, the attached patch removes the flickering for me. I saw
> the cursor blink once, but I couldn't reproduce that and I couldn't get it
> to do it again.
>
> The patch is not suitable for applying to master as it certainly breaks
> something int he tty child frame code, but hopefully it gives you an idea
> of what the problem might be. I'm going to experiment with accounting for
> the NULL frame in the space glyph and see if that helps.
>
> Aaron
>
Actually, while I don't fully understand the code, it seems suspect to me
that there is a global `space_glyph` glyph struct that gets initialized
with a NULL frame but the frame is mutated over time. I wonder if my not
removing the frame check inside of CHAR_GLYPH_SPACE_P is why I saw the
cursor flicker once.
> On Sun, Mar 16, 2025 at 2:00 AM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
> wrote:
>
>> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>>
>> One other thing, it may be related to tab-bar mode. It seems to be
>> connected to when I switch tabs — one tab has a vterm buffer scrolling
>> output and the other just has a grep output, for example. If I don't get
>> the flicker in the grep output, I can switch back and forth between the two
>> tabs a couple times and I'll start to get it.
>>
>> Doesn't ring a bell, I'm afraid. Tab bar, AFAIU it, is "just playing with
>> window configurations". Why that would lead to flickering, I can't imagine
>> ATM.
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 17:45:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Aaron
On Sun, Mar 16, 2025 at 10:19 AM, Aaron Jensen <aaronjensen <at> gmail.com>
wrote:
> On Sun, Mar 16, 2025 at 10:15 AM, Aaron Jensen <aaronjensen <at> gmail.com>
> wrote:
>
>> Hi,
>>
>> I've narrowed it down to the addition to frame in the glyph comparison.
>> As far as I can tell, the attached patch removes the flickering for me. I
>> saw the cursor blink once, but I couldn't reproduce that and I couldn't get
>> it to do it again.
>>
>> The patch is not suitable for applying to master as it certainly breaks
>> something int he tty child frame code, but hopefully it gives you an idea
>> of what the problem might be. I'm going to experiment with accounting for
>> the NULL frame in the space glyph and see if that helps.
>>
>> Aaron
>>
>
> Actually, while I don't fully understand the code, it seems suspect to me
> that there is a global `space_glyph` glyph struct that gets initialized
> with a NULL frame but the frame is mutated over time. I wonder if my not
> removing the frame check inside of CHAR_GLYPH_SPACE_P is why I saw the
> cursor flicker once.
>
I was mistaken here, I believe. It's not mutated over time — I'm just rusty
on C and I misread some code.
Aaron
>
>> On Sun, Mar 16, 2025 at 2:00 AM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> wrote:
>>
>>> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>>>
>>> One other thing, it may be related to tab-bar mode. It seems to be
>>> connected to when I switch tabs — one tab has a vterm buffer scrolling
>>> output and the other just has a grep output, for example. If I don't get
>>> the flicker in the grep output, I can switch back and forth between the two
>>> tabs a couple times and I'll start to get it.
>>>
>>> Doesn't ring a bell, I'm afraid. Tab bar, AFAIU it, is "just playing
>>> with window configurations". Why that would lead to flickering, I can't
>>> imagine ATM.
>>>
>>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 19:27:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Aaron Jensen <aaronjensen <at> gmail.com> writes:
> Hi,
>
> I've narrowed it down to the addition to frame in the glyph
> comparison. As far as I can tell, the attached patch removes the
> flickering for me. I saw the cursor blink once, but I couldn't
> reproduce that and I couldn't get it to do it again.
>
> The patch is not suitable for applying to master as it certainly
> breaks something int he tty child frame code, but hopefully it gives
> you an idea of what the problem might be. I'm going to experiment with
> accounting for the NULL frame in the space glyph and see if that
> helps.
Thanks Aaron, that was very helpful. I'm pretty sure it gave me right
idea, namely... This in adjust_glyph_matrix
dispnew.c:
505 while (row < end)
506 {
507 row->glyphs[LEFT_MARGIN_AREA] =
508 xnrealloc (row->glyphs[LEFT_MARGIN_AREA],
509 dim.width, sizeof (struct glyph));
means that glyphs in window-system windows are not zeroed. Which in turn
means that glyph::frame is not guaranteed to be NULL initially. And
because I falsely assumed that to be the case, I didn't change the code
producing glyphs for window-systems to set glyph::frame, which isn't
needed or used on window-systems. And in the end, the glyph comparisons
can fail.
Or so is the hypothesis...
Could you please try if the attached change works for you (without your
patch)?
[adjust.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 19:36:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Aaron Jensen <aaronjensen <at> gmail.com> writes:
> Actually, while I don't fully understand the code, it seems suspect
> to me that there is a global `space_glyph` glyph struct that gets
> initialized with a NULL frame but the frame is mutated over time. I
> wonder if my not removing the frame check inside of
> CHAR_GLYPH_SPACE_P is why I saw the cursor flicker once.
>
> I was mistaken here, I believe. It's not mutated over time — I'm just
> rusty on C and I misread some code.
And the redisplay code is pretty complicated, I must admit. Much of
which is due to the slowness of mid-90s computers and pressing something
with acceptable performance out of that 🤷.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 19:38:04 GMT)
Full text and
rfc822 format available.
Message #59 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 16, 2025 at 12:25 PM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> Hi,
>
> I've narrowed it down to the addition to frame in the glyph comparison. As
> far as I can tell, the attached patch removes the flickering for me. I saw
> the cursor blink once, but I couldn't reproduce that and I couldn't get it
> to do it again.
>
> The patch is not suitable for applying to master as it certainly breaks
> something int he tty child frame code, but hopefully it gives you an idea
> of what the problem might be. I'm going to experiment with accounting for
> the NULL frame in the space glyph and see if that helps.
>
> Thanks Aaron, that was very helpful. I'm pretty sure it gave me right
> idea, namely... This in adjust_glyph_matrix
>
> dispnew.c:
> 505 while (row < end)
> 506 {
> 507 row->glyphs[LEFT_MARGIN_AREA] = 508 xnrealloc
> (row->glyphs[LEFT_MARGIN_AREA], 509 dim.width, sizeof (struct glyph));
>
> means that glyphs in window-system windows are not zeroed. Which in turn
> means that glyph::frame is not guaranteed to be NULL initially. And because
> I falsely assumed that to be the case, I didn't change the code producing
> glyphs for window-systems to set glyph::frame, which isn't needed or used
> on window-systems. And in the end, the glyph comparisons can fail.
>
> Or so is the hypothesis...
>
> Could you please try if the attached change works for you (without your
> patch)?
>
I was just about to send you log output that showed seemingly random values
in glyph::frame. You beat me to it.
This patch appears to fix the problem for me, thank you.
Is this the only place that they need to be initialized? Was it more than
glyph::frame that was uninitialized (and was that problematic)?
For my own edification, while logging GLYPH_EQUAL_P, I noticed that it's
invoked frequently for windows/buffers that are not visible. As in, while a
hidden vterm buffer is accumulating log output and I only have a single
stationary buffer visible, I see a flood of log messages. Is this expected?
It may very well be, I just don't know much about the rendering pipeline.
Thanks,
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 20:14:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Aaron Jensen <aaronjensen <at> gmail.com> writes:
> Could you please try if the attached change works for you (without your patch)?
>
> I was just about to send you log output that showed seemingly random
> values in glyph::frame. You beat me to it.
👍
> This patch appears to fix the problem for me, thank you.
Thanks.
> Is this the only place that they need to be initialized? Was it more
> than glyph::frame that was uninitialized (and was that problematic)?
adjust_glyph_matrix is the only place where these glyph allocations
happen, for window-systems. For completeness, let be just say that
glyphs matrices on ttys function differently. And the whole struct
glyphs in a glyph row were uninitialized because they are allocated via
C's realloc. I don't think this being uninitialized was a problem
before, the problem was only the combination with my assumption that the
memory was zeroed. Don't know where that assumption came from. Maybe
I've misread them, or maybe it's just that I hate leaving memory
uninitialized in general and assumed I wouldn't have done it there. No
idea.
> For my own edification, while logging GLYPH_EQUAL_P, I noticed that
> it's invoked frequently for windows/buffers that are not visible. As
> in, while a hidden vterm buffer is accumulating log output and I only
> have a single stationary buffer visible, I see a flood of log
> messages. Is this expected? It may very well be, I just don't know
> much about the rendering pipeline.
That sounds suspicious. So you have one window W displaying some
innocuous buffer B, and another vterm buffer V that is not displayed
anywhere. The shell in V runs something producing output. That does not
change B, and also not something visible in W, including mode-line or
such or maybe frame title. And that leads to some redisplay of W?
Does that also happen when you use something else than vterm, say M-x
shell or M-x eshell?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 20:32:04 GMT)
Full text and
rfc822 format available.
Message #65 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>> This patch appears to fix the problem for me, thank you.
>
Now pushed. Thanks for the very helpful hint!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 16 Mar 2025 21:21:03 GMT)
Full text and
rfc822 format available.
Message #68 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 16, 2025 at 1:13 PM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> Could you please try if the attached change works for you (without your
> patch)?
>
> I was just about to send you log output that showed seemingly random
> values in glyph::frame. You beat me to it.
>
> 👍
>
> This patch appears to fix the problem for me, thank you.
>
> Thanks.
>
> Is this the only place that they need to be initialized? Was it more than
> glyph::frame that was uninitialized (and was that problematic)?
>
> adjust_glyph_matrix is the only place where these glyph allocations
> happen, for window-systems. For completeness, let be just say that glyphs
> matrices on ttys function differently. And the whole struct glyphs in a
> glyph row were uninitialized because they are allocated via C's realloc. I
> don't think this being uninitialized was a problem before, the problem was
> only the combination with my assumption that the memory was zeroed. Don't
> know where that assumption came from. Maybe I've misread them, or maybe
> it's just that I hate leaving memory uninitialized in general and assumed I
> wouldn't have done it there. No idea.
>
> For my own edification, while logging GLYPH_EQUAL_P, I noticed that it's
> invoked frequently for windows/buffers that are not visible. As in, while a
> hidden vterm buffer is accumulating log output and I only have a single
> stationary buffer visible, I see a flood of log messages. Is this expected?
> It may very well be, I just don't know much about the rendering pipeline.
>
> That sounds suspicious. So you have one window W displaying some innocuous
> buffer B, and another vterm buffer V that is not displayed anywhere. The
> shell in V runs something producing output. That does not change B, and
> also not something visible in W, including mode-line or such or maybe frame
> title. And that leads to some redisplay of W?
>
Yes, all of that is true. I can't say whether or not it leads to a
redisplay of W, I just know right now that it leads to glyph comparisons
and somehow that leads to flickering in W, so maybe that's enough to infer
that it's a redisplay of W.
Does that also happen when you use something else than vterm, say M-x shell
> or M-x eshell?
>
Yes, it happens with shell and term as well
Now pushed. Thanks for the very helpful hint!
Thank you for the quick fix.
Is it clear to you why the glyph comparison failing would lead to
flickering, even with double buffering enabled?
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Mon, 17 Mar 2025 04:21:03 GMT)
Full text and
rfc822 format available.
Message #71 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Aaron Jensen <aaronjensen <at> gmail.com> writes:
> That sounds suspicious. So you have one window W displaying some
> innocuous buffer B, and another vterm buffer V that is not displayed
> anywhere. The shell in V runs something producing output. That does
> not change B, and also not something visible in W, including
> mode-line or such or maybe frame title. And that leads to some
> redisplay of W?
>
> Yes, all of that is true. I can't say whether or not it leads to a
> redisplay of W, I just know right now that it leads to glyph
> comparisons and somehow that leads to flickering in W, so maybe that's
> enough to infer that it's a redisplay of W.
I think one can say that, yes. The glyph comparisons are done in the
part of redisplay that I call "update" which writes to the screen.
(Looking at redisplay from sufficient height, how it works is like this,
for a window on a window-system frame: It maintains two glyph matrices,
the so-called current and the desired one. The current glyph matrix
corresponds 1:1 to what is currently visible on the screen, and the
desired one represents what should be on the screen. Redisplay builds
the desired one, then compares current and desired matrix, and writes
the difference to the screen. That's of course a gross simplification.
Anyway, the comparison step above is where these "equal macros" come
into play. So we're pretty deep in redisplay, I'd say. BTW, there's a
large comment at the start of xdisp.c which explains it hopefully
a bit better, should you be interested.)
> Does that also happen when you use something else than vterm, say M-x shell or M-x eshell?
>
> Yes, it happens with shell and term as well
To me that looks as if this shouldn't happen. At least judging from what
I remember from the times of Emacs 21.
Maybe Eli has an idea what could cause this. It might be worth submitting
another bug for this.
> Now pushed. Thanks for the very helpful hint!
>
> Thank you for the quick fix.
>
> Is it clear to you why the glyph comparison failing would lead to
> flickering, even with double buffering enabled?
Heard about the double-buffering feature the first time yesterday, I
think. I had it in a branch in Emacs 21, but I guess it's not that one
:-). Or IOW, no idea. It might depend on how that's implemented.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Mon, 17 Mar 2025 12:40:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> Cc: Alan Third <alan <at> idiocy.org>, 77039 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Mon, 17 Mar 2025 05:20:11 +0100
>
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> > Does that also happen when you use something else than vterm, say M-x shell or M-x eshell?
> >
> > Yes, it happens with shell and term as well
>
> To me that looks as if this shouldn't happen. At least judging from what
> I remember from the times of Emacs 21.
>
> Maybe Eli has an idea what could cause this. It might be worth submitting
> another bug for this.
If you are talking about comparing glyph matrices of windows/frames
that are not shown, that shouldn't happen. If it seems to happen, I'd
need a clear recipe where it does, which I could run on GNU/Linux or
MS-Windows, to debug this. Windows that are not displayed don't even
have desired matrices to compare, so I don't think I understand how
this could be possible.
> > Is it clear to you why the glyph comparison failing would lead to
> > flickering, even with double buffering enabled?
>
> Heard about the double-buffering feature the first time yesterday, I
> think. I had it in a branch in Emacs 21, but I guess it's not that one
> :-). Or IOW, no idea. It might depend on how that's implemented.
If glyph comparison fails, Emacs will redraw the screen. Whether it
should be visible with double-buffering depends on how that was
implemented on macOS, and what exactly "flickers" as part of
"flickering".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Mon, 17 Mar 2025 15:57:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 17, 2025 at 5:39 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> Cc: Alan Third <alan <at> idiocy.org>, 77039 <at> debbugs.gnu.org From: Gerd
> Möllmann <gerd.moellmann <at> gmail.com> Date: Mon, 17 Mar 2025 05:20:11 +0100
>
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> Does that also happen when you use something else than vterm, say M-x
> shell or M-x eshell?
>
> Yes, it happens with shell and term as well
>
> To me that looks as if this shouldn't happen. At least judging from what I
> remember from the times of Emacs 21.
>
> Maybe Eli has an idea what could cause this. It might be worth submitting
> another bug for this.
>
> If you are talking about comparing glyph matrices of windows/frames that
> are not shown, that shouldn't happen. If it seems to happen, I'd need a
> clear recipe where it does, which I could run on GNU/Linux or MS-Windows,
> to debug this. Windows that are not displayed don't even have desired
> matrices to compare, so I don't think I understand how this could be
> possible.
>
It's more likely that an update in a hidden buffer is causing a glyph
comparison on the displayed buffer given that it's the one that is
flickering. Because the buffer is updating so rapidly, this happens often.
The hidden buffer is connected to an external process. You can simulate
this by running `yes` in a `term` and then hiding that buffer. Is that
expected?
> Is it clear to you why the glyph comparison failing would lead to
> flickering, even with double buffering enabled?
>
> Heard about the double-buffering feature the first time yesterday, I
> think. I had it in a branch in Emacs 21, but I guess it's not that one
> :-). Or IOW, no idea. It might depend on how that's implemented.
>
> If glyph comparison fails, Emacs will redraw the screen. Whether it should
> be visible with double-buffering depends on how that was implemented on
> macOS, and what exactly "flickers" as part of
> "flickering".
>
Ok, then yea it's very possible that the particular method used is
susceptible to flickering. Thanks.
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Mon, 17 Mar 2025 16:39:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Mon, 17 Mar 2025 15:56:00 +0000
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, alan <at> idiocy.org,
> 77039 <at> debbugs.gnu.org
>
> If you are talking about comparing glyph matrices of windows/frames that are not shown, that shouldn't
> happen. If it seems to happen, I'd need a clear recipe where it does, which I could run on GNU/Linux or
> MS-Windows, to debug this. Windows that are not displayed don't even have desired matrices to
> compare, so I don't think I understand how this could be possible.
>
> It's more likely that an update in a hidden buffer is causing a glyph comparison on the displayed buffer given
> that it's the one that is flickering. Because the buffer is updating so rapidly, this happens often. The hidden
> buffer is connected to an external process. You can simulate this by running `yes` in a `term` and then
> hiding that buffer. Is that expected?
I don't think I understand the situation. If you can show some Lisp
to simulate that, it would help.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Mon, 17 Mar 2025 17:16:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Mar 17, 2025 at 9:38 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Mon, 17 Mar 2025 15:56:00 +0000
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, alan <at> idiocy.org, 77039@
> debbugs.gnu.org
>
> If you are talking about comparing glyph matrices of windows/frames that
> are not shown, that shouldn't happen. If it seems to happen, I'd need a
> clear recipe where it does, which I could run on GNU/Linux or MS-Windows,
> to debug this. Windows that are not displayed don't even have desired
> matrices to compare, so I don't think I understand how this could be
> possible.
>
> It's more likely that an update in a hidden buffer is causing a glyph
> comparison on the displayed buffer given that it's the one that is
> flickering. Because the buffer is updating so rapidly, this happens often.
> The hidden buffer is connected to an external process. You can simulate
> this by running `yes` in a `term` and then hiding that buffer. Is that
> expected?
>
> I don't think I understand the situation. If you can show some Lisp to
> simulate that, it would help.
>
Not Lisp, but:
emacs -Q
M-x shell
yes<enter>
C-x b<enter>
This will open a shell in a background buffer that is rapidly printing to
STDOUT (and displaying in the shell buffer) then switch to the scratch
buffer. If you add logging to the matrix comparisons you will see a rapid
uptick. I don't know if this has to do with the external process connection
with Emacs.
To be clear, I don't know if this is actually an issue given that the
matrix comparison is likely preventing the redisplay.
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Tue, 18 Mar 2025 06:04:04 GMT)
Full text and
rfc822 format available.
Message #86 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Aaron Jensen <aaronjensen <at> gmail.com> writes:
> Not Lisp, but:
>
> emacs -Q
> M-x shell
> yes<enter>
> C-x b<enter>
>
> This will open a shell in a background buffer that is rapidly printing to STDOUT (and displaying in
> the shell buffer) then switch to the scratch buffer. If you add logging to the matrix comparisons you
> will see a rapid uptick. I don't know if this has to do with the external process connection with
> Emacs.
>
> To be clear, I don't know if this is actually an issue given that the matrix comparison is likely
> preventing the redisplay.
>
> Aaron
When I configure with --enable-checking=glyphs, and run, in emacs -Q,
GUI version the function
(defun foo ()
(interactive)
(trace-redisplay 1)
(term "/usr/bin/yes")
(switch-to-buffer "*scratch*"))
I see traces of the form
redisplay_preserve_echo_area (12)
redisplay_internal 0
redisplay_preserve_echo_area (12)
redisplay_internal 0
...
The 12 means the call is from wait_reading_process_output, which reads
the output from /usr/bin/yes in this case.
So, that explains where the redisplay comes from. Since there are no
further redisplay actions shown in the trace output, I think that
redisplay is more or less a nop in these cases. Didn't try without the
fix that I pushed.
Why wait_reading_process_output is called with argument do_display ==
true I have no idea.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Tue, 18 Mar 2025 07:56:03 GMT)
Full text and
rfc822 format available.
Message #89 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
>> Not Lisp, but:
>>
>> emacs -Q
>> M-x shell
>> yes<enter>
>> C-x b<enter>
>>
>> This will open a shell in a background buffer that is rapidly printing to STDOUT (and displaying in
>> the shell buffer) then switch to the scratch buffer. If you add logging to the matrix comparisons you
>> will see a rapid uptick. I don't know if this has to do with the external process connection with
>> Emacs.
>>
>> To be clear, I don't know if this is actually an issue given that the matrix comparison is likely
>> preventing the redisplay.
>>
>> Aaron
>
> When I configure with --enable-checking=glyphs, and run, in emacs -Q,
> GUI version the function
>
> (defun foo ()
> (interactive)
> (trace-redisplay 1)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
>
> I see traces of the form
>
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> ...
>
> The 12 means the call is from wait_reading_process_output, which reads
> the output from /usr/bin/yes in this case.
>
> So, that explains where the redisplay comes from. Since there are no
> further redisplay actions shown in the trace output, I think that
> redisplay is more or less a nop in these cases. Didn't try without the
> fix that I pushed.
>
> Why wait_reading_process_output is called with argument do_display ==
> true I have no idea.
From reading the code a bit, where wait_reading_process_output is
called, calling it with do_display == true looks okay to me. It is
sometimes necessary to redisplay, and checking the cases where it isn't
is probably similarly expensive as just doing the redisplay.
So, I propose to close the bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Tue, 18 Mar 2025 13:20:03 GMT)
Full text and
rfc822 format available.
Message #92 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> Date: Tue, 18 Mar 2025 07:02:53 +0100
>
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> > Not Lisp, but:
> >
> > emacs -Q
> > M-x shell
> > yes<enter>
> > C-x b<enter>
> >
> > This will open a shell in a background buffer that is rapidly printing to STDOUT (and displaying in
> > the shell buffer) then switch to the scratch buffer. If you add logging to the matrix comparisons you
> > will see a rapid uptick. I don't know if this has to do with the external process connection with
> > Emacs.
> >
> > To be clear, I don't know if this is actually an issue given that the matrix comparison is likely
> > preventing the redisplay.
> >
> > Aaron
>
> When I configure with --enable-checking=glyphs, and run, in emacs -Q,
> GUI version the function
>
> (defun foo ()
> (interactive)
> (trace-redisplay 1)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
>
> I see traces of the form
>
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> ...
>
> The 12 means the call is from wait_reading_process_output, which reads
> the output from /usr/bin/yes in this case.
>
> So, that explains where the redisplay comes from. Since there are no
> further redisplay actions shown in the trace output, I think that
> redisplay is more or less a nop in these cases. Didn't try without the
> fix that I pushed.
Yes, redisplay should be a nop, since the buffer which is modified is
not displayed.
But Aaron seems to say we keep comparing the glyph matrices of the
window which is not show, something that should not happen, because we
don't call update_frame on frames that are not visible.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Tue, 18 Mar 2025 14:05:03 GMT)
Full text and
rfc822 format available.
Message #95 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> But Aaron seems to say we keep comparing the glyph matrices of the
> window which is not show, something that should not happen, because we
> don't call update_frame on frames that are not visible.
Maybe Aaron could log __FILE__ and __LINE__ where he said he logged the
frames in the macros?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Tue, 18 Mar 2025 14:11:03 GMT)
Full text and
rfc822 format available.
Message #98 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: aaronjensen <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> Date: Tue, 18 Mar 2025 15:04:24 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > But Aaron seems to say we keep comparing the glyph matrices of the
> > window which is not show, something that should not happen, because we
> > don't call update_frame on frames that are not visible.
>
> Maybe Aaron could log __FILE__ and __LINE__ where he said he logged the
> frames in the macros?
That would help, yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Tue, 18 Mar 2025 15:33:03 GMT)
Full text and
rfc822 format available.
Message #101 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 18, 2025 at 6:19 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz@
> gnu.org>, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org Date: Tue, 18 Mar 2025
> 07:02:53 +0100
>
> Aaron Jensen <aaronjensen <at> gmail.com> writes:
>
> Not Lisp, but:
>
> emacs -Q
> M-x shell
> yes<enter>
> C-x b<enter>
>
> This will open a shell in a background buffer that is rapidly printing to
> STDOUT (and displaying in the shell buffer) then switch to the scratch
> buffer. If you add logging to the matrix comparisons you will see a rapid
> uptick. I don't know if this has to do with the external process connection
> with Emacs.
>
> To be clear, I don't know if this is actually an issue given that the
> matrix comparison is likely preventing the redisplay.
>
> Aaron
>
> When I configure with --enable-checking=glyphs, and run, in emacs -Q, GUI
> version the function
>
> (defun foo ()
> (interactive)
> (trace-redisplay 1)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
>
> I see traces of the form
>
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> redisplay_preserve_echo_area (12)
> redisplay_internal 0
> ...
>
> The 12 means the call is from wait_reading_process_output, which reads the
> output from /usr/bin/yes in this case.
>
> So, that explains where the redisplay comes from. Since there are no
> further redisplay actions shown in the trace output, I think that redisplay
> is more or less a nop in these cases. Didn't try without the fix that I
> pushed.
>
> Yes, redisplay should be a nop, since the buffer which is modified is not
> displayed.
>
> But Aaron seems to say we keep comparing the glyph matrices of the window
> which is not show, something that should not happen, because we don't call
> update_frame on frames that are not visible.
>
I tried to explain that I wasn't convinced that it was that, that it could
have, and even likely was, a redisplay of the currently displayed buffer
(which is why *it* was flickering). Unless anyone thinks that there is
reason to investigate further, I'm satisfied with the answer that reading
process output can cause a comparison of glyphs, which is unlikely to
result in a redisplay of an unrelated buffer.
If you'd like me to try the FILE/LINE logging, please let me know and I'd
be happy to do it.
Thanks,
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Tue, 18 Mar 2025 16:54:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Tue, 18 Mar 2025 15:32:41 +0000
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, alan <at> idiocy.org,
> 77039 <at> debbugs.gnu.org
>
> Yes, redisplay should be a nop, since the buffer which is modified is not displayed.
>
> But Aaron seems to say we keep comparing the glyph matrices of the window which is not show,
> something that should not happen, because we don't call update_frame on frames that are not visible.
>
> I tried to explain that I wasn't convinced that it was that, that it could have, and even likely was, a redisplay of
> the currently displayed buffer (which is why *it* was flickering). Unless anyone thinks that there is reason to
> investigate further, I'm satisfied with the answer that reading process output can cause a comparison of
> glyphs, which is unlikely to result in a redisplay of an unrelated buffer.
Reading process output is not supposed to cause comparison of glyphs
if the buffer to which process output is directed is not being
displayed. So if you do see glyphs being compared in that case, we
should look into that. The only glyphs that could be legitimately
compared in that case are those on the mode line.
> If you'd like me to try the FILE/LINE logging, please let me know and I'd be happy to do it.
If the above means you see something that shouldn't happen, then yes,
please provide the traces.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 16:18:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 18, 2025 at 9:52 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Tue, 18 Mar 2025 15:32:41 +0000
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, alan <at> idiocy.org, 77039@
> debbugs.gnu.org
>
> Yes, redisplay should be a nop, since the buffer which is modified is not
> displayed.
>
> But Aaron seems to say we keep comparing the glyph matrices of the window
> which is not show, something that should not happen, because we don't call
> update_frame on frames that are not visible.
>
> I tried to explain that I wasn't convinced that it was that, that it could
> have, and even likely was, a redisplay of the currently displayed buffer
> (which is why *it* was flickering). Unless anyone thinks that there is
> reason to investigate further, I'm satisfied with the answer that reading
> process output can cause a comparison of glyphs, which is unlikely to
> result in a redisplay of an unrelated buffer.
>
> Reading process output is not supposed to cause comparison of glyphs if
> the buffer to which process output is directed is not being displayed. So
> if you do see glyphs being compared in that case, we should look into that.
> The only glyphs that could be legitimately compared in that case are those
> on the mode line.
>
In my config, I definitely see matrix comparisons when hidden buffers are
updated. It's row_equal_p and update_text_area that are called in rapid
succession even when the shell buffer is not visible. I tried disabling
both my tab bar and my header line (I don't use a mode line) and I still
saw it updating.
Here's an example log output, this repeats as quickly as yes emits "y"
dispnew.c:4775
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:1295
dispnew.c:4775
I can't reproduce this with emacs -Q, unfortunately. It seems to be have as
you described. Hidden buffers do not cause comparisons.
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 16:43:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sat, 22 Mar 2025 09:17:08 -0700
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>
> In my config, I definitely see matrix comparisons when hidden buffers are updated. It's row_equal_p and
> update_text_area that are called in rapid succession even when the shell buffer is not visible. I tried
> disabling both my tab bar and my header line (I don't use a mode line) and I still saw it updating.
>
> Here's an example log output, this repeats as quickly as yes emits "y"
>
> dispnew.c:4775
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:4775
Is the mode_line_p flag of the glyph row set when these comparisons
are made?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 16:48:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Mar 22, 2025 at 9:41 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sat, 22 Mar 2025 09:17:08 -0700
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>
> In my config, I definitely see matrix comparisons when hidden buffers are
> updated. It's row_equal_p and update_text_area that are called in rapid
> succession even when the shell buffer is not visible. I tried disabling
> both my tab bar and my header line (I don't use a mode line) and I still
> saw it updating.
>
> Here's an example log output, this repeats as quickly as yes emits "y"
>
> dispnew.c:4775
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:4775
>
> Is the mode_line_p flag of the glyph row set when these comparisons are
> made?
>
I see this:
update_text_area updated_row->mode_line_p: 0
update_text_area updated_row->mode_line_p: 1
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
… Many more of these in each iteration …
So it's set in one update_text_area, but not another.
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 17:10:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sat, 22 Mar 2025 09:47:47 -0700
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>
> On Sat, Mar 22, 2025 at 9:41 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sat, 22 Mar 2025 09:17:08 -0700
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>
> In my config, I definitely see matrix comparisons when hidden buffers are updated. It's
> row_equal_p and update_text_area that are called in rapid succession even when the shell
> buffer is not visible. I tried disabling both my tab bar and my header line (I don't use a mode line)
> and I still saw it updating.
>
> Here's an example log output, this repeats as quickly as yes emits "y"
>
> dispnew.c:4775
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:1295
> dispnew.c:4775
>
> Is the mode_line_p flag of the glyph row set when these comparisons are made?
>
> I see this:
>
> update_text_area updated_row->mode_line_p: 0
> update_text_area updated_row->mode_line_p: 1
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
> … Many more of these in each iteration …
>
> So it's set in one update_text_area, but not another.
I'm afraid you will need to come up with a reproduction recipe for
this, so that we could investigate what causes this. Maybe it's a bug
or maybe I'm missing something.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 17:45:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Aaron Jensen <aaronjensen <at> gmail.com>
>> Date: Sat, 22 Mar 2025 09:47:47 -0700
>> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>>
>> On Sat, Mar 22, 2025 at 9:41 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> From: Aaron Jensen <aaronjensen <at> gmail.com>
>> Date: Sat, 22 Mar 2025 09:17:08 -0700
>> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>>
>> In my config, I definitely see matrix comparisons when hidden buffers are updated. It's
>> row_equal_p and update_text_area that are called in rapid succession even when the shell
>> buffer is not visible. I tried disabling both my tab bar and my header line (I don't use a mode line)
>> and I still saw it updating.
>>
>> Here's an example log output, this repeats as quickly as yes emits "y"
>>
>> dispnew.c:4775
>> dispnew.c:1295
>> dispnew.c:1295
>> dispnew.c:1295
>> dispnew.c:1295
>> dispnew.c:1295
>> dispnew.c:1295
>> dispnew.c:1295
>> dispnew.c:4775
>>
>> Is the mode_line_p flag of the glyph row set when these comparisons are made?
>>
>> I see this:
>>
>> update_text_area updated_row->mode_line_p: 0
>> update_text_area updated_row->mode_line_p: 1
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> row_equal_p a->mode_line_p: 0 b->mode_line_p: 0
>> … Many more of these in each iteration …
>>
>> So it's set in one update_text_area, but not another.
>
> I'm afraid you will need to come up with a reproduction recipe for
> this, so that we could investigate what causes this. Maybe it's a bug
> or maybe I'm missing something.
If it's something in Aaron's config, maybe he could bisect this. I'd
also look for something doing things to mode-line-format first, maybe.
But I also have no real idea what that is.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 19:23:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Aaron Jensen <aaronjensen <at> gmail.com>, alan <at> idiocy.org,
> 77039 <at> debbugs.gnu.org
> Date: Sat, 22 Mar 2025 18:43:58 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I'm afraid you will need to come up with a reproduction recipe for
> > this, so that we could investigate what causes this. Maybe it's a bug
> > or maybe I'm missing something.
>
> If it's something in Aaron's config, maybe he could bisect this.
I hope so.
> I'd also look for something doing things to mode-line-format first,
> maybe. But I also have no real idea what that is.
Given that the glyph rows in question have their mode_line_p flag
reset, is that still a possibility?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 20:21:03 GMT)
Full text and
rfc822 format available.
Message #125 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Aaron Jensen <aaronjensen <at> gmail.com>, alan <at> idiocy.org,
>> 77039 <at> debbugs.gnu.org
>> Date: Sat, 22 Mar 2025 18:43:58 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I'm afraid you will need to come up with a reproduction recipe for
>> > this, so that we could investigate what causes this. Maybe it's a bug
>> > or maybe I'm missing something.
>>
>> If it's something in Aaron's config, maybe he could bisect this.
>
> I hope so.
>
>> I'd also look for something doing things to mode-line-format first,
>> maybe. But I also have no real idea what that is.
>
> Given that the glyph rows in question have their mode_line_p flag
> reset, is that still a possibility?
Hm, probably not.
But could this make a difference?
dispnew.c:
5261 static int
5262 scrolling_window (struct window *w, int tab_line_p)
5263 {
5264 struct glyph_matrix *desired_matrix = w->desired_matrix;
5265 struct glyph_matrix *current_matrix = w->current_matrix;
5266 int yb = window_text_bottom_y (w);
5267 ptrdiff_t i;
5268 int j, first_old, first_new, last_old, last_new;
5269 int nruns, run_idx;
5270 ptrdiff_t n;
5271 struct row_entry *entry;
5272 struct redisplay_interface *rif = FRAME_RIF (XFRAME (WINDOW_FRAME (w)));
5273
5274 /* Skip over rows equal at the start. */
5275 for (i = tab_line_p; i < current_matrix->nrows - 1; ++i)
^^^^^^^^^^
(That can apparently be 0, 1, or 2. Bad name.)
5276 {
5277 struct glyph_row *d = MATRIX_ROW (desired_matrix, i);
5278 struct glyph_row *c = MATRIX_ROW (current_matrix, i);
5279
5280 /* If there is a row with a stipple currently on the glass, give
5281 up. Stipples look different depending on where on the
5282 display they are drawn, so scrolling the display will produce
5283 incorrect results. */
5284
5285 if (c->stipple_p)
5286 return 0;
^^^^^^^^^^^^^^^^^
What's that stipple thing? Aaron, could that stipple be different
with an without your config?
5287
5288 if (c->enabled_p
5289 && d->enabled_p
5290 && !d->redraw_fringe_bitmaps_p
Or something in the fringes?
5291 && c->y == d->y
5292 && MATRIX_ROW_BOTTOM_Y (c) <= yb
5293 && MATRIX_ROW_BOTTOM_Y (d) <= yb
5294 && row_equal_p (c, d, 1))
But that's clueless guessing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 20:33:05 GMT)
Full text and
rfc822 format available.
Message #128 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: aaronjensen <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> Date: Sat, 22 Mar 2025 21:20:09 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> I'd also look for something doing things to mode-line-format first,
> >> maybe. But I also have no real idea what that is.
> >
> > Given that the glyph rows in question have their mode_line_p flag
> > reset, is that still a possibility?
>
> Hm, probably not.
>
> But could this make a difference?
>
>
> dispnew.c:
> 5261 static int
> 5262 scrolling_window (struct window *w, int tab_line_p)
Why would scrolling_window be called at all if we never call
update_window for buffers that are not shown in any window?
AFAIU, the scenario is that the sub-process is inserting text into a
buffer that isn't shown in any window on display. In this case,
redisplay is supposed to conclude that no window needs to be redrawn,
and if so, update_window will not be called for any window. Right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 20:41:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: aaronjensen <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>> Date: Sat, 22 Mar 2025 21:20:09 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> I'd also look for something doing things to mode-line-format first,
>> >> maybe. But I also have no real idea what that is.
>> >
>> > Given that the glyph rows in question have their mode_line_p flag
>> > reset, is that still a possibility?
>>
>> Hm, probably not.
>>
>> But could this make a difference?
>>
>>
>> dispnew.c:
>> 5261 static int
>> 5262 scrolling_window (struct window *w, int tab_line_p)
>
> Why would scrolling_window be called at all if we never call
> update_window for buffers that are not shown in any window?
>
> AFAIU, the scenario is that the sub-process is inserting text into a
> buffer that isn't shown in any window on display. In this case,
> redisplay is supposed to conclude that no window needs to be redrawn,
> and if so, update_window will not be called for any window. Right?
Right, and I agree. I'm trying to find a way to explain the difference
that Aaron sees with and without his config. Otherwise I have no idea
how to proceed with this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sat, 22 Mar 2025 21:39:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Mar 22, 2025 at 1:40 PM, Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: aaronjensen <at> gmail.com,
> alan <at> idiocy.org, 77039 <at> debbugs.gnu.org Date: Sat, 22 Mar 2025 21:20:09
> +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> I'd also look for something doing things to mode-line-format first, maybe.
> But I also have no real idea what that is.
>
> Given that the glyph rows in question have their mode_line_p flag reset,
> is that still a possibility?
>
> Hm, probably not.
>
> But could this make a difference?
>
> dispnew.c:
> 5261 static int
> 5262 scrolling_window (struct window *w, int tab_line_p)
>
> Why would scrolling_window be called at all if we never call update_window
> for buffers that are not shown in any window?
>
> AFAIU, the scenario is that the sub-process is inserting text into a
> buffer that isn't shown in any window on display. In this case, redisplay
> is supposed to conclude that no window needs to be redrawn, and if so,
> update_window will not be called for any window. Right?
>
> Right, and I agree. I'm trying to find a way to explain the difference
> that Aaron sees with and without his config. Otherwise I have no idea how
> to proceed with this.
>
It's global-display-line-numbers-mode.
Repro from emacs -Q:
(defun foo ()
(Interactive)
(global-display-line-numbers-mode)
(term "/usr/bin/yes")
(switch-to-buffer "*scratch*"))
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 04:57:04 GMT)
Full text and
rfc822 format available.
Message #137 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Aaron Jensen <aaronjensen <at> gmail.com> writes:
> Right, and I agree. I'm trying to find a way to explain the difference that Aaron sees with and
> without his config. Otherwise I have no idea how to proceed with this.
>
> It's global-display-line-numbers-mode.
>
> Repro from emacs -Q:
>
> (defun foo ()
> (Interactive)
> (global-display-line-numbers-mode)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
>
> Aaron
Thanks! I think I see now what's going on.
redisplay_internal has this (line numbers may differ):
xdisp.c:
17368 && (NILP (Vdisplay_line_numbers)
17369 || EQ (Vdisplay_line_numbers, Qvisual))
This means that certain redisplay optimizations that make redisplay
particularly "cheap" are not tried, depending on line number display.
Instead the more expensive redisplay methods are used that consider
whole windows or parts of them and so on. Or, in other words, line
number display can make redisplay less of a nop.
So, with line numbers, hidden buffer with process ->
wait_reading_process_output -> redisplay_internal -> update_window (or
similar) -> ... -> row_equal_p -> the equal macros
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 05:11:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Mar 22 , 2025 at 9:56 PM, Gerd Möllmann < gerd.moellmann <at> gmail.com > wrote:
>
>
>
>
>
> Aaron Jensen < aaronjensen <at> gmail.com > writes:
>
>
>
>>
>>
>> Right, and I agree. I'm trying to find a way to explain the difference
>> that Aaron sees with and
>> without his config. Otherwise I have no idea how to proceed with this.
>>
>>
>
>
>
> >
>
>
>
>>
>>
>> It's global-display-line-numbers-mode.
>>
>>
>>
>
>
>
> >
>
>
>
>>
>>
>> Repro from emacs -Q:
>>
>>
>>
>
>
>
> >
>
>
>
>>
>>
>> (defun foo ()
>> (Interactive)
>> (global-display-line-numbers-mode)
>> (term "/usr/bin/yes")
>> (switch-to-buffer "*scratch*"))
>>
>>
>
>
>
> >
>
>
>
>>
>>
>> Aaron
>>
>>
>>
>
>
>
> Thanks! I think I see now what's going on.
>
>
>
>
> redisplay_internal has this (line numbers may differ):
>
>
>
>
> xdisp.c:
> 17368 && (NILP (Vdisplay_line_numbers) 17369 || EQ (Vdisplay_line_numbers,
> Qvisual))
>
>
>
> This means that certain redisplay optimizations that make redisplay
> particularly "cheap" are not tried, depending on line number display.
>
>
>
>
> Instead the more expensive redisplay methods are used that consider whole
> windows or parts of them and so on. Or, in other words, line number
> display can make redisplay less of a nop.
>
>
>
>
> So, with line numbers, hidden buffer with process ->
> wait_reading_process_output -> redisplay_internal -> update_window (or
> similar) -> ... -> row_equal_p -> the equal macros
>
>
>
>
My vterm buffers do not have line numbers, so it sounds like it's considering the line number status of the currently visible window, does that sound right?
And it looks like there's a FIXME comment right above it:
```
/* FIXME: The following condition is only needed when
significant parts of the buffer are hidden (e.g., under
hs-minor-mode), but there doesn't seem to be a simple way of
detecting that, so we always disable the one-line redisplay
optimizations whenever display-line-numbers-mode is turned on
in the buffer. */
Thanks,
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 05:42:03 GMT)
Full text and
rfc822 format available.
Message #143 received at 77039 <at> debbugs.gnu.org (full text, mbox):
"Aaron Jensen" <aaronjensen <at> gmail.com> writes:
> Thanks! I think I see now what's going on.
>
> redisplay_internal has this (line numbers may differ):
>
> xdisp.c:
> 17368 && (NILP (Vdisplay_line_numbers) 17369 || EQ (Vdisplay_line_numbers, Qvisual))
>
> This means that certain redisplay optimizations that make redisplay particularly "cheap" are not
> tried, depending on line number display.
>
> Instead the more expensive redisplay methods are used that consider whole windows or parts of them
> and so on. Or, in other words, line number display can make redisplay less of a nop.
>
> So, with line numbers, hidden buffer with process -> wait_reading_process_output ->
> redisplay_internal -> update_window (or similar) -> ... -> row_equal_p -> the equal macros
>
> My vterm buffers do not have line numbers, so it sounds like it's
> considering the line number status of the currently visible window,
> does that sound right?
Yes, it's the value in current_buffer. Don't see ATM where that is set,
but it's normally the buffer of the selected window. Maybe that's
implicitly the case if consider_all_windows is false.
>
> And it looks like there's a FIXME comment right above it:
>
> ```
> /* FIXME: The following condition is only needed when
> significant parts of the buffer are hidden (e.g., under
> hs-minor-mode), but there doesn't seem to be a simple way of
> detecting that, so we always disable the one-line redisplay
> optimizations whenever display-line-numbers-mode is turned on
> in the buffer. */
Yeah, I've seen that, but I couldn't figure out what circumstance
prevents using the optimizations in this case, specifically when line
numbers are displayed. An enigma :-).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 07:59:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> Date: Sun, 23 Mar 2025 05:56:41 +0100
>
> > Repro from emacs -Q:
> >
> > (defun foo ()
> > (Interactive)
> > (global-display-line-numbers-mode)
> > (term "/usr/bin/yes")
> > (switch-to-buffer "*scratch*"))
> >
> > Aaron
>
> Thanks! I think I see now what's going on.
>
> redisplay_internal has this (line numbers may differ):
>
> xdisp.c:
> 17368 && (NILP (Vdisplay_line_numbers)
> 17369 || EQ (Vdisplay_line_numbers, Qvisual))
>
> This means that certain redisplay optimizations that make redisplay
> particularly "cheap" are not tried, depending on line number display.
See bug#54091.
> Instead the more expensive redisplay methods are used that consider
> whole windows or parts of them and so on. Or, in other words, line
> number display can make redisplay less of a nop.
Yes, and there's little wonder it's so: certain changes in the buffer
and point position could potentially have effect on line numbers of
lines that are not involved in the change, so more thorough redisplay
is needed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 08:00:03 GMT)
Full text and
rfc822 format available.
Message #149 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sat, 22 Mar 2025 17:38:01 -0400
> Cc: Eli Zaretskii <eliz <at> gnu.org>, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>
> It's global-display-line-numbers-mode.
>
> Repro from emacs -Q:
>
> (defun foo ()
> (Interactive)
> (global-display-line-numbers-mode)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
If you set display-line-numbers-mode to 'visual globally, does the
problem go away?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 08:05:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: "Eli Zaretskii" <eliz <at> gnu.org>, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> Date: Sun, 23 Mar 2025 06:41:10 +0100
>
> "Aaron Jensen" <aaronjensen <at> gmail.com> writes:
>
> > Thanks! I think I see now what's going on.
> >
> > redisplay_internal has this (line numbers may differ):
> >
> > xdisp.c:
> > 17368 && (NILP (Vdisplay_line_numbers) 17369 || EQ (Vdisplay_line_numbers, Qvisual))
> >
> > This means that certain redisplay optimizations that make redisplay particularly "cheap" are not
> > tried, depending on line number display.
> >
> > Instead the more expensive redisplay methods are used that consider whole windows or parts of them
> > and so on. Or, in other words, line number display can make redisplay less of a nop.
> >
> > So, with line numbers, hidden buffer with process -> wait_reading_process_output ->
> > redisplay_internal -> update_window (or similar) -> ... -> row_equal_p -> the equal macros
> >
> > My vterm buffers do not have line numbers, so it sounds like it's
> > considering the line number status of the currently visible window,
> > does that sound right?
>
> Yes, it's the value in current_buffer. Don't see ATM where that is set,
> but it's normally the buffer of the selected window. Maybe that's
> implicitly the case if consider_all_windows is false.
Of course, it's from the current buffer. But we forgot the effect of
blink-cursor-mode, which forces a (minor) redisplay cycle every 0.5
sec, and requires to at least redraw the character under the cursor.
So turning off blink-cursor-mode should perhaps prevent the problem.
Does it?
> > And it looks like there's a FIXME comment right above it:
> >
> > ```
> > /* FIXME: The following condition is only needed when
> > significant parts of the buffer are hidden (e.g., under
> > hs-minor-mode), but there doesn't seem to be a simple way of
> > detecting that, so we always disable the one-line redisplay
> > optimizations whenever display-line-numbers-mode is turned on
> > in the buffer. */
>
> Yeah, I've seen that, but I couldn't figure out what circumstance
> prevents using the optimizations in this case, specifically when line
> numbers are displayed. An enigma :-).
Not an enigma: "git annotate" points to a certain bug which was the
trigger for the addition of this condition.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 08:17:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 23, 2025 at 12:59 AM, Eli Zaretskii < eliz <at> gnu.org > wrote:
>
>
>>
>>
>>
>>
>>
>> From: Aaron Jensen < aaronjensen@ gmail. com ( aaronjensen <at> gmail.com ) >
>>
>> Date: Sat , 22 Mar 2025 17:38:01 -0400
>>
>> Cc: Eli Zaretskii < eliz@ gnu. org ( eliz <at> gnu.org ) >, alan@ idiocy. org (
>> alan <at> idiocy.org ) , 77039@ debbugs. gnu. org ( 77039 <at> debbugs.gnu.org )
>>
>>
>>
>>
>>
>>
>>
>>
>> It's global-display-line-numbers-mode.
>>
>>
>>
>>
>> Repro from emacs -Q:
>>
>>
>>
>>
>>
>>
>>
>> (defun foo ()
>>
>> (Interactive)
>>
>> (global-display-line-numbers-mode)
>>
>> (term "/usr/bin/yes")
>>
>> (switch-to-buffer "*scratch*"))
>>
>>
>>
>>
>>
>>
>>
>
>
>
> If you set display-line-numbers-mode to 'visual globally, does the problem
> go away?
>
>
>
>
No, nor does disabling blink cursor mode or commenting out the lines you referenced.
I'm using this, please double check I'm not doing something wrong.
(defun foo ()
(interactive)
(blink-cursor-mode -1)
(global-display-line-numbers-mode)
(setq-default display-line-numbers-mode 'visual)
(term "/usr/bin/yes")
(switch-to-buffer "*scratch*"))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 09:14:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> From: "Aaron Jensen" <aaronjensen <at> gmail.com>
> Date: Sun, 23 Mar 2025 08:16:18 +0000
>
> (defun foo ()
> (Interactive)
> (global-display-line-numbers-mode)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
>
> If you set display-line-numbers-mode to 'visual globally, does the problem go away?
>
> No, nor does disabling blink cursor mode or commenting out the lines you referenced.
>
> I'm using this, please double check I'm not doing something wrong.
>
> (defun foo ()
> (interactive)
> (blink-cursor-mode -1)
> (global-display-line-numbers-mode)
> (setq-default display-line-numbers-mode 'visual)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
Then the conditions mention by Gerd are not the ones at play here. Or
maybe I'm missing something else.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 09:26:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 77039 <at> debbugs.gnu.org (full text, mbox):
"Aaron Jensen" <aaronjensen <at> gmail.com> writes:
> On Sun, Mar 23, 2025 at 12:59 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sat, 22 Mar 2025 17:38:01 -0400
> Cc: Eli Zaretskii <eliz <at> gnu.org>, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>
> It's global-display-line-numbers-mode.
>
> Repro from emacs -Q:
>
> (defun foo ()
> (Interactive)
> (global-display-line-numbers-mode)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
>
> If you set display-line-numbers-mode to 'visual globally, does the problem go away?
>
> No, nor does disabling blink cursor mode or commenting out the lines you referenced.
>
> I'm using this, please double check I'm not doing something wrong.
>
> (defun foo ()
> (interactive)
> (blink-cursor-mode -1)
> (global-display-line-numbers-mode)
> (setq-default display-line-numbers-mode 'visual)
^^^^^
Vdisplay_line_numbers = display-line-numbers. Also, I would set it before
activating the mode because setq-default doesn't change existing
buffer-local bindings.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 09:33:06 GMT)
Full text and
rfc822 format available.
Message #164 received at 77039 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>> Date: Sun, 23 Mar 2025 05:56:41 +0100
>>
>> > Repro from emacs -Q:
>> >
>> > (defun foo ()
>> > (Interactive)
>> > (global-display-line-numbers-mode)
>> > (term "/usr/bin/yes")
>> > (switch-to-buffer "*scratch*"))
>> >
>> > Aaron
>>
>> Thanks! I think I see now what's going on.
>>
>> redisplay_internal has this (line numbers may differ):
>>
>> xdisp.c:
>> 17368 && (NILP (Vdisplay_line_numbers)
>> 17369 || EQ (Vdisplay_line_numbers, Qvisual))
>>
>> This means that certain redisplay optimizations that make redisplay
>> particularly "cheap" are not tried, depending on line number display.
>
> See bug#54091.
Thanks, but it's still an enigma for me :-). I've never used
hs-minor-mode and don't know how it is implemented. Is it the old
selective display, and something the OP did that changed it that way?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 09:45:05 GMT)
Full text and
rfc822 format available.
Message #167 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: aaronjensen <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> Date: Sun, 23 Mar 2025 10:32:29 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> redisplay_internal has this (line numbers may differ):
> >>
> >> xdisp.c:
> >> 17368 && (NILP (Vdisplay_line_numbers)
> >> 17369 || EQ (Vdisplay_line_numbers, Qvisual))
> >>
> >> This means that certain redisplay optimizations that make redisplay
> >> particularly "cheap" are not tried, depending on line number display.
> >
> > See bug#54091.
>
> Thanks, but it's still an enigma for me :-). I've never used
> hs-minor-mode and don't know how it is implemented. Is it the old
> selective display, and something the OP did that changed it that way?
No, it uses an overlay with 'invisible' property. See hs-make-overlay
in hideshow.el.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 10:14:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> From: "Aaron Jensen" <aaronjensen <at> gmail.com>
> Date: Sun, 23 Mar 2025 08:16:18 +0000
>
>
> On Sun, Mar 23, 2025 at 12:59 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sat, 22 Mar 2025 17:38:01 -0400
> Cc: Eli Zaretskii <eliz <at> gnu.org>, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
>
> It's global-display-line-numbers-mode.
>
> Repro from emacs -Q:
>
> (defun foo ()
> (Interactive)
> (global-display-line-numbers-mode)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
>
> If you set display-line-numbers-mode to 'visual globally, does the problem go away?
>
> No, nor does disabling blink cursor mode or commenting out the lines you referenced.
>
> I'm using this, please double check I'm not doing something wrong.
>
> (defun foo ()
> (interactive)
> (blink-cursor-mode -1)
> (global-display-line-numbers-mode)
> (setq-default display-line-numbers-mode 'visual)
> (term "/usr/bin/yes")
> (switch-to-buffer "*scratch*"))
My testing indicates that setting display-line-numbers-mode to
'visual' does stop redisplay of the selected window. I did that with
a simple "M-x set-variable", not with the globalized mode.
And I did misinterpret the code in redisplay_internal: when
display-line-numbers-mode is not nil and not 'visual', we currently go
ahead with calling redisplay_window, and there I think we use the
method marked with "1" here:
/* Try to redisplay starting at same place as before.
If point has not moved off frame, accept the results. */
if (!current_matrix_up_to_date_p
/* Don't use try_window_reusing_current_matrix in this case
because a window scroll function can have changed the
buffer. */
|| !NILP (Vwindow_scroll_functions)
|| MINI_WINDOW_P (w)
|| !(used_current_matrix_p
= try_window_reusing_current_matrix (w)))
{
IF_DEBUG (debug_method_add (w, "1")); <<<<<<<<<<<<<<<<<<<
clear_glyph_matrix (w->desired_matrix);
if (try_window (window, startp, TRY_WINDOW_CHECK_MARGINS) < 0)
/* -1 means we need to scroll.
0 means we need new matrices, but fonts_changed
is set in that case, so we will detect it below. */
goto try_to_scroll;
}
because try_window_reusing_current_matrix also gives up when
line-numbers are shown.
So in summary, I don't see anything abnormal here. If we want to keep
the only-current-line-changed optimization in redisplay_internal,
someone will have to come up with a smarter test for when line numbers
are shown. I think the underlying problem is that when the line
number of the current line becomes large enough to require more
columns for line-number display, we must redraw the entire window to
avoid the problem with shifting or line number described in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54091#5 .
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 10:38:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> Date: Sun, 23 Mar 2025 12:13:10 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> So in summary, I don't see anything abnormal here. If we want to keep
> the only-current-line-changed optimization in redisplay_internal,
> someone will have to come up with a smarter test for when line numbers
> are shown. I think the underlying problem is that when the line
> number of the current line becomes large enough to require more
> columns for line-number display, we must redraw the entire window to
> avoid the problem with shifting or line number described in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54091#5 .
To clarify: this should not cause any flickering, AFAIU, because the
comparison of glyphs in subroutines of update_frame is supposed to
find that everything on the glass is already up-to-date and there's no
need to draw anything. So flickering, which happens because portions
of the window are actually redrawn on the glass, should not happen in
this case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 16:04:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 23, 2025 at 3:37 AM, Eli Zaretskii < eliz <at> gnu.org > wrote:
>
>
>>
>>
>> Cc: gerd. moellmann@ gmail. com ( gerd.moellmann <at> gmail.com ) , alan@ idiocy.
>> org ( alan <at> idiocy.org ) , 77039@ debbugs. gnu. org ( 77039 <at> debbugs.gnu.org
>> ) Date: Sun , 23 Mar 2025 12:13:10 +0200
>> From: Eli Zaretskii < eliz@ gnu. org ( eliz <at> gnu.org ) >
>>
>>
>>
>> So in summary, I don't see anything abnormal here. If we want to keep the
>> only-current-line-changed optimization in redisplay_internal, someone will
>> have to come up with a smarter test for when line numbers are shown. I
>> think the underlying problem is that when the line number of the current
>> line becomes large enough to require more columns for line-number display,
>> we must redraw the entire window to avoid the problem with shifting or
>> line number described in https:/ / debbugs. gnu. org/ cgi/ bugreport. cgi?bug=54091#5
>> ( https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54091#5 ).
>>
>>
>>
>
>
>
> To clarify: this should not cause any flickering, AFAIU, because the
> comparison of glyphs in subroutines of update_frame is supposed to find
> that everything on the glass is already up-to-date and there's no need to
> draw anything. So flickering, which happens because portions of the window
> are actually redrawn on the glass, should not happen in this case.
>
>
>
>
Right, I don't observe any flickering. Am I correct that it is only comparing the glyphs on the current line? If so, that doesn't seem like a huge problem, even though it is (in most cases?) technically extra work.
Aaron
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 16:40:10 GMT)
Full text and
rfc822 format available.
Message #179 received at 77039 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 23 Mar 2025 16:03:17 +0000
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> From: "Aaron Jensen" <aaronjensen <at> gmail.com>
>
> On Sun, Mar 23, 2025 at 3:37 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org Date: Sun, 23 Mar 2025
> 12:13:10 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> So in summary, I don't see anything abnormal here. If we want to keep the
> only-current-line-changed optimization in redisplay_internal, someone will have to come up with a
> smarter test for when line numbers are shown. I think the underlying problem is that when the line
> number of the current line becomes large enough to require more columns for line-number
> display, we must redraw the entire window to avoid the problem with shifting or line number
> described in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54091#5 .
>
> To clarify: this should not cause any flickering, AFAIU, because the comparison of glyphs in
> subroutines of update_frame is supposed to find that everything on the glass is already up-to-date and
> there's no need to draw anything. So flickering, which happens because portions of the window are
> actually redrawn on the glass, should not happen in this case.
>
> Right, I don't observe any flickering.
OK, so I think we are good.
> Am I correct that it is only comparing the glyphs on the current
> line?
No, I think in the case we were analyzing it compares the glyphs of
the entire window, or its large parts.
> If
> so, that doesn't seem like a huge problem, even though it is (in most cases?) technically extra work.
For this extra work to be spared, someone has to devise a method of
examining the buffer and the window before actually redrawing it, and
deciding that no update is needed, and do it cheaply enough to yield
net savings.
You should keep in mind the basic problem redisplay needs to solve.
It doesn't react to each and every change in the buffers and other
structures that affect display. Instead, it is called when Emacs
thinks it's good time to maybe redisplay, and it needs to decide, just
by looking at the buffers as they are at that time, what has changed
since last redisplay and how those changes might affect the windows on
display. When the first phase of redisplay cannot safely exclude the
need for redrawing a window or some of its parts, it produces the
"desired" glyph matrices for those parts, which describe how those
parts _should_ look, and leaves it to the second phase to decide what,
if anything, should actually be redrawn on the glass, by comparing the
desired matrix with the current matrix (which describes what _is_ on
the glass). Thus, this second phase, which is where the comparison of
the glyphs happens, is the "last line of defense" against unnecessary
redrawing, which would otherwise cause flickering and is relatively
expensive.
It is in many cases impossible to know whether a particular change in
buffer text will require large portions of a window to be redrawn,
without actually doing the layout work that produces the desired
matrix. That's because the layout of glyphs is a complex process with
many tricky rules, which all but preclude fast and cheap decisions
like that except in very simple cases. For example, insertion of a
single character in a middle of bidirectional text can completely
change the way characters are laid out on the glass. So the simple
cases are detected and handled by "redisplay optimizations" of the
first phase of redisplay, and the rest is left to the second phase,
which prevents unnecessary redraws based on glyph comparison.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#77039; Package
emacs.
(Sun, 23 Mar 2025 16:56:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 77039 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Mar 23, 2025 at 9:39 AM, Eli Zaretskii < eliz <at> gnu.org > wrote:
>
>
>>
>>
>> Date: Sun , 23 Mar 2025 16:03:17 +0000
>> Cc: gerd. moellmann@ gmail. com ( gerd.moellmann <at> gmail.com ) , alan@ idiocy.
>> org ( alan <at> idiocy.org ) , 77039@ debbugs. gnu. org ( 77039 <at> debbugs.gnu.org
>> ) From: "Aaron Jensen" < aaronjensen@ gmail. com ( aaronjensen <at> gmail.com )
>> >
>>
>>
>>
>> On Sun, Mar 23, 2025 at 3:37 AM, Eli Zaretskii < eliz@ gnu. org (
>> eliz <at> gnu.org ) > wrote:
>>
>>
>>
>>
>> Cc: gerd. moellmann@ gmail. com ( gerd.moellmann <at> gmail.com ) , alan@ idiocy.
>> org ( alan <at> idiocy.org ) , 77039@ debbugs. gnu. org ( 77039 <at> debbugs.gnu.org
>> ) Date: Sun , 23 Mar 2025 12:13:10 +0200
>> From: Eli Zaretskii < eliz@ gnu. org ( eliz <at> gnu.org ) >
>>
>>
>>
>> So in summary, I don't see anything abnormal here. If we want to keep the
>> only-current-line-changed optimization in redisplay_internal, someone will
>> have to come up with a smarter test for when line numbers are shown. I
>> think the underlying problem is that when the line number of the current
>> line becomes large enough to require more columns for line-number display,
>> we must redraw the entire window to avoid the problem with shifting or
>> line number described in https:/ / debbugs. gnu. org/ cgi/ bugreport. cgi?bug=54091#5
>> ( https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54091#5 ).
>>
>>
>>
>>
>> To clarify: this should not cause any flickering, AFAIU, because the
>> comparison of glyphs in subroutines of update_frame is supposed to find
>> that everything on the glass is already up-to-date and there's no need to
>> draw anything. So flickering, which happens because portions of the window
>> are actually redrawn on the glass, should not happen in this case.
>>
>>
>>
>>
>> Right, I don't observe any flickering.
>>
>>
>>
>
>
>
> OK, so I think we are good.
>
>
>
>>
>>
>> Am I correct that it is only comparing the glyphs on the current line?
>>
>>
>>
>
>
>
> No, I think in the case we were analyzing it compares the glyphs of the
> entire window, or its large parts.
>
>
>
>>
>>
>> If
>> so, that doesn't seem like a huge problem, even though it is (in most
>> cases?) technically extra work.
>>
>>
>
>
>
> For this extra work to be spared, someone has to devise a method of
> examining the buffer and the window before actually redrawing it, and
> deciding that no update is needed, and do it cheaply enough to yield net
> savings.
>
>
>
>
> You should keep in mind the basic problem redisplay needs to solve. It
> doesn't react to each and every change in the buffers and other structures
> that affect display. Instead, it is called when Emacs thinks it's good
> time to maybe redisplay, and it needs to decide, just by looking at the
> buffers as they are at that time, what has changed since last redisplay
> and how those changes might affect the windows on display. When the first
> phase of redisplay cannot safely exclude the need for redrawing a window
> or some of its parts, it produces the
> "desired" glyph matrices for those parts, which describe how those parts
> _should_ look, and leaves it to the second phase to decide what, if
> anything, should actually be redrawn on the glass, by comparing the
> desired matrix with the current matrix (which describes what _is_ on the
> glass). Thus, this second phase, which is where the comparison of the
> glyphs happens, is the "last line of defense" against unnecessary
> redrawing, which would otherwise cause flickering and is relatively
> expensive.
>
>
>
> It is in many cases impossible to know whether a particular change in
> buffer text will require large portions of a window to be redrawn, without
> actually doing the layout work that produces the desired matrix. That's
> because the layout of glyphs is a complex process with many tricky rules,
> which all but preclude fast and cheap decisions like that except in very
> simple cases. For example, insertion of a single character in a middle of
> bidirectional text can completely change the way characters are laid out
> on the glass. So the simple cases are detected and handled by "redisplay
> optimizations" of the first phase of redisplay, and the rest is left to
> the second phase, which prevents unnecessary redraws based on glyph
> comparison.
>
>
>
>
Thank you for the detailed response. Unless I'm missing something, it sounds like we can close this. I don't know if the FIXME comment is worth removing (or perhaps replaced with an explanation, rather than an expressed intent to correct).
Aside from that, with the flicker gone, I'm happy. Thank you all.
Aaron
[Message part 2 (text/html, inline)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 29 Mar 2025 10:41:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Aaron Jensen <aaronjensen <at> gmail.com>:
bug acknowledged by developer.
(Sat, 29 Mar 2025 10:41:02 GMT)
Full text and
rfc822 format available.
Message #187 received at 77039-done <at> debbugs.gnu.org (full text, mbox):
> Cc: gerd.moellmann <at> gmail.com, alan <at> idiocy.org, 77039 <at> debbugs.gnu.org
> From: "Aaron Jensen" <aaronjensen <at> gmail.com>
> Date: Sun, 23 Mar 2025 16:55:02 +0000
>
> Thank you for the detailed response. Unless I'm missing something, it sounds like we can close this. I don't
> know if the FIXME comment is worth removing (or perhaps replaced with an explanation, rather than an
> expressed intent to correct).
>
> Aside from that, with the flicker gone, I'm happy. Thank you all.
I'm therefore closing this bug.
I don't think the FIXME comment should be removed, as the solution
there is not the best one.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 26 Apr 2025 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.