* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized @ 2018-03-04 17:38 Aaron Jensen 2018-03-04 20:27 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Aaron Jensen @ 2018-03-04 17:38 UTC (permalink / raw) To: 30699 Now that undecorated frames are a reality, some cool stuff is happening like posframe: https://github.com/tumashu/posframe and https://github.com/tumashu/ivy-posframe posframe creates and manages child frames at a position in a buffer. It uses `fit-frame-to-buffer' to resize frames. It appears that (on macOS, at least) when a frame is resized, there is an unsightly flicker. It does not matter if the frame is undecorated or not. Here is a repro. It requires posframe, but that's just because it was easier to set up this way for me. I'm sure it could be reproduced with vanilla emacs functions: (require 'posframe) (setq my-timer (run-with-timer 0 0.2 (lambda () (posframe-show " *my-posframe-buffer*" :string "hello" :min-width 10 :min-height 10 :position 1) (run-with-timer 0.1 nil (lambda () (posframe-show " *my-posframe-buffer*" :min-width 10 :min-height 11 :position 1)))))) To end the flicker storm: (cancel-timer my-timer) (posframe-delete-all) For reference, this was originally reported here: https://github.com/tumashu/ivy-posframe/issues/7 In GNU Emacs 26.0.91 (build 1, x86_64-apple-darwin17.4.0, NS appkit-1561.20 Version 10.13.3 (Build 17D102)) of 2018-03-02 built on aaron-mbt.local Repository revision: 6719f05ff75ec19e45e40b98d8b0c6184168ac5e Windowing system distributor 'Apple', version 10.3.1561 Recent messages: syntax-ppss: Lisp nesting exceeds ‘max-lisp-eval-depth’ Search failed: there is an unmatched expression somewhere or we are at the beginning/end of file. [12 times] Indenting region...done Saving file /Users/aaronjensen/Dropbox (Personal)/Notes/refile.org... Wrote /Users/aaronjensen/Dropbox (Personal)/Notes/refile.org g c Saving file /Users/aaronjensen/.emacs.d/elpa/26.0/develop/posframe-20180227.305/posframe.el... Wrote /Users/aaronjensen/.emacs.d/elpa/26.0/develop/posframe-20180227.305/posframe.el Wrote /Users/aaronjensen/.emacs.d/elpa/26.0/develop/posframe-20180227.305/posframe.elc Wrote /Users/aaronjensen/.emacs.d/elpa/26.0/develop/posframe-20180227.305/posframe.{el,elc} Configured using: 'configure --disable-dependency-tracking --disable-silent-rules --enable-locallisppath=/usr/local/share/emacs/site-lisp --infodir=/usr/local/Cellar/emacs-plus/HEAD-6719f05/share/info/emacs --prefix=/usr/local/Cellar/emacs-plus/HEAD-6719f05 --with-xml2 --without-dbus --with-gnutls --with-imagemagick --with-modules --with-rsvg --with-ns --disable-ns-self-contained' Configured features: JPEG RSVG IMAGEMAGICK NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS LCMS2 Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: company-statistics-mode: t company-childframe-mode: t company-mode: t auto-compile-mode: t elisp-slime-nav-mode: t eros-mode: t lispyville-mode: t lispy-mode: t nameless-mode: t goto-address-prog-mode: t auto-highlight-symbol-mode: t dtrt-indent-mode: t highlight-numbers-mode: t highlight-parentheses-mode: t rainbow-delimiters-mode: t yas-global-mode: t yas-minor-mode: t bug-reference-prog-mode: t diff-auto-refine-mode: t magit-auto-revert-mode: t auto-dim-other-buffers-mode: t global-git-gutter+-mode: t git-gutter+-mode: t global-git-commit-mode: t async-bytecomp-package-mode: t projectile-mode: t recentf-mode: t persp-mode: t desktop-save-mode: t global-wakatime-mode: t wakatime-mode: t evil-mc-mode: t hl-todo-mode: t global-spacemacs-whitespace-cleanup-mode: t spacemacs-whitespace-cleanup-mode: t ws-butler-global-mode: t ws-butler-mode: t winum-mode: t winner-mode: t pupo-mode: t purpose-mode: t global-vi-tilde-fringe-mode: t vi-tilde-fringe-mode: t save-place-mode: t savehist-mode: t global-origami-mode: t origami-mode: t Info-breadcrumbs-in-mode-line-mode: t flycheck-pos-tip-mode: t global-flycheck-mode: t flx-ido-mode: t eyebrowse-mode: t global-evil-surround-mode: t evil-surround-mode: t global-evil-search-highlight-persist: t evil-search-highlight-persist: t show-smartparens-global-mode: t show-smartparens-mode: t evil-lion-mode: t evil-escape-mode: t global-anzu-mode: t anzu-mode: t eval-sexp-fu-flash-mode: t editorconfig-mode: t counsel-mode: t ivy-mode: t delete-selection-mode: t clean-aindent-mode: t hybrid-mode: t which-key-mode: t override-global-mode: t global-undo-tree-mode: t undo-tree-mode: t evil-mode: t evil-local-mode: t spacemacs-leader-override-mode: t global-spacemacs-leader-override-mode: t global-hl-line-mode: t xterm-mouse-mode: t global-auto-revert-mode: t shell-dirtrack-mode: t ido-vertical-mode: t global-page-break-lines-mode: t page-break-lines-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t hs-minor-mode: t Load-path shadows: /Users/aaronjensen/.emacs.d/elpa/26.0/develop/ht-20180129.1434/ht hides /Users/aaronjensen/.emacs.d/core/libs/ht /Users/aaronjensen/.emacs.d/elpa/26.0/develop/inf-ruby-20180226.1511/inf-ruby hides /usr/local/share/emacs/site-lisp/ruby/inf-ruby /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-stan hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-stan /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-exp hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-exp /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-J hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-J /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-eshell hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-eshell /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-emacs-lisp hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-emacs-lisp /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-gnus hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-gnus /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-css hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-css /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-lob hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-lob /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-forth hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-forth /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-macs hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-macs /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-version hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-version /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-scheme hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-scheme /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-abc hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-abc /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-C hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-C /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-capture hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-capture /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-ref hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-ref /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-clojure hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-clojure /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-mouse hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-mouse /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-ledger hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-ledger /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-ctags hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-ctags /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-entities hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-entities /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-archive hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-archive /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-screen hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-screen /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-haskell hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-haskell /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-asymptote hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-asymptote /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-mhe hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-mhe /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-table hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-table /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-keys hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-keys /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-org hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-org /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-plot hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-plot /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-awk hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-awk /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-groovy hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-groovy /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-octave hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-octave /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-faces hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-faces /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-colview hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-colview /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-R hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-R /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-timer hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-timer /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-ebnf hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-ebnf /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-mobile hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-mobile /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-fortran hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-fortran /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-shell hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-shell /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-perl hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-perl /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-sqlite hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-sqlite /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-sed hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-sed /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-list hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-list /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-ruby hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-ruby /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-eval hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-eval /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-habit hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-habit /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-clock hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-clock /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-html hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-html /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-src hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-src /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-lisp hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-lisp /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-ditaa hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-ditaa /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-pcomplete hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-pcomplete /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-lint hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-lint /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-rmail hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-rmail /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-latex hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-latex /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-sass hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-sass /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-io hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-io /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-tangle hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-tangle /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-calc hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-calc /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-java hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-java /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-icalendar hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-icalendar /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-eww hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-eww /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-md hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-md /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-beamer hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-beamer /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-element hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-element /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-protocol hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-protocol /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-mscgen hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-mscgen /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-gnuplot hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-gnuplot /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-latex hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-latex /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-id hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-id /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-vala hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-vala /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-man hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-man /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-feed hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-feed /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-lua hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-lua /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-table hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-table /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-ocaml hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-ocaml /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-coq hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-coq /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-picolisp hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-picolisp /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-indent hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-indent /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-lilypond hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-lilypond /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-matlab hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-matlab /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-datetree hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-datetree /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-python hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-python /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-bbdb hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-bbdb /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-makefile hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-makefile /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-duration hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-duration /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-agenda hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-agenda /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-dot hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-dot /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-js hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-js /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-publish hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-publish /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-inlinetask hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-inlinetask /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-org hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-org /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-core hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-core /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-compat hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-compat /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-docview hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-docview /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-odt hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-odt /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-plantuml hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-plantuml /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-ascii hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-ascii /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-loaddefs hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-loaddefs /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-w3m hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-w3m /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-bibtex hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-bibtex /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-info hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-info /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-hledger hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-hledger /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-maxima hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-maxima /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-macro hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-macro /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-sql hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-sql /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-attach hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-attach /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-processing hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-processing /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ox-texinfo hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ox-texinfo /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-irc hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-irc /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-crypt hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-crypt /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-footnote hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-footnote /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/org-install hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/org-install /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-comint hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-comint /Users/aaronjensen/.emacs.d/elpa/26.0/develop/org-plus-contrib-20180226/ob-shen hides /usr/local/Cellar/emacs-plus/HEAD-6719f05/share/emacs/26.0.91/lisp/org/ob-shen Features: (shadow sort mail-extr evil-nerd-commenter evil-nerd-commenter-operator evil-nerd-commenter-sdk misearch multi-isearch counsel-projectile tmux emacsbug sendmail smex appt diary-lib diary-loaddefs epa-file org-agenda executable pp vc-git org-gcal org-archive request-deferred deferred request alert log4e notifications dbus xml gntp company-tng eieio-opt speedbar sb-image ezimage dframe colir tabify shrink-path open-junk-file company-emoji company-emoji-list org-eldoc evil-org org-table ob-shell ob-ruby ob-restclient restclient ob-http ob-http-mode ob-elixir company-statistics company-files company-keywords company-dabbrev-code company-dabbrev company-capf company-childframe posframe company overseer pkg-info epl f auto-compile packed elisp-slime-nav eros flycheck-package package-lint finder lispyville lispy iedit iedit-lib multiple-cursors-core lispy-inline avy semantic/db semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local cedet evil-ediff ediff-merg ediff-wind ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff edebug lispy-tags nameless goto-addr auto-highlight-symbol dtrt-indent highlight-numbers parent-mode highlight-parentheses hideshow rainbow-delimiters org-bullets org-download toc-org yasnippet-snippets yasnippet elec-pair org-indent image-file org-rmail org-mhe org-irc org-info org-gnus nnir gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader org-docview doc-view jka-compr image-mode org-bibtex bibtex org-bbdb org-w3m org-checklist org-inlinetask smartparens-org ox-gfm ox-md ox-reveal 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 ox-html table ox-ascii ox-publish ox orgit org-element avl-tree generator magithub magithub-dash magithub-notification magithub-issue-view magithub-comment magithub-repo magithub-orgs magithub-issue-tricks magithub-issue-post magithub-edit-mode magithub-ci magithub-issue magithub-label magithub-user magithub-core magithub-faces magithub-settings smartparens-markdown markdown-mode bug-reference ghub+ apiwrap apropos evil-magit git-rebase magit-gh-pulls gh gh-users gh-issues gh-pulls gh-repos gh-comments gh-gist gh-oauth gh-api logito gh-cache gh-auth gh-url url-http tls gnutls url-gw nsm magit-obsolete magit-blame magit-stash magit-bisect magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-collab ghub url-auth url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log magit-diff smerge-mode diff-mode magit-core magit-autorevert magit-process magit-margin magit-mode org org-macro org-footnote org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint ob-core ob-eval org-compat org-macs org-loaddefs cal-menu calendar cal-loaddefs editorconfig-core editorconfig-core-handle editorconfig-fnmatch face-remap auto-dim-other-buffers git-gutter-fringe+ fringe-helper git-gutter+ git-commit with-editor magit-git magit-section magit-utils crm magit-popup async-bytecomp async log-edit message rmc puny rfc822 mml mml-sec epa gnus-util rmail rmail-loaddefs mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log projectile grep recentf tree-widget persp-mode desktop frameset wakatime-mode contextual-menubar quiet-emacs fill-or-unfill init-macos-terminal-copy-paste init-flyspell init-terminal-cursor evil-terminal-cursor-changer init-org init-magit 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 hl-todo persistent-soft list-utils pcache eieio-base font-utils server zone spacemacs-whitespace-cleanup ws-butler winum winner spacemacs-purpose-popwin window-purpose-x imenu-list imenu ibuf-ext ibuffer ibuffer-loaddefs window-purpose window-purpose-fixes window-purpose-prefix-overload window-purpose-switch window-purpose-layout window-purpose-core window-purpose-configuration window-purpose-utils vi-tilde-fringe unicode-fonts smartparens-config smartparens-text saveplace savehist popwin osx-trash origami origami-parsers linum ivy-hydra info+ flycheck-pos-tip pos-tip flycheck find-func flx-ido eyebrowse evil-surround evil-search-highlight-persist evil-numbers evil-lisp-state smartparens evil-lion evil-indent-plus evil-exchange evil-escape evil-anzu anzu eval-sexp-fu highlight font-lock+ frame-fns avoid editorconfig noutline outline doom-modeline let-alist powerline-separators color all-the-icons all-the-icons-faces data-material data-weathericons data-octicons data-fileicons data-faicons data-alltheicons memoize counsel dired dired-loaddefs compile esh-util etags xref project swiper ivy flx delsel ivy-overlay ffap clean-aindent-mode gh-common gh-profile s marshal dash rx docker-tramp tramp-cache hybrid-mode exec-path-from-shell evil-evilified-state which-key use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core hydra lv cus-edit cus-start cus-load evil evil-integration undo-tree diff evil-maps evil-commands reveal flyspell ispell evil-jumps evil-command-window evil-types evil-search evil-ex evil-macros evil-repeat evil-states evil-core evil-common windmove thingatpt rect evil-digraphs diminish evil-vars bind-map quelpa help-fns radix-tree package-build mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr json map lisp-mnt hl-line xt-mouse autorevert filenotify cl-extra disp-table wid-edit monokai-theme info finder-inf patch-server init-sass init-php init-html init-evil tramp tramp-compat tramp-loaddefs trampver shell pcomplete comint ansi-color ring parse-time format-spec ido-vertical-mode ido core-spacemacs core-use-package-ext core-transient-state core-micro-state core-toggle core-keybindings core-fonts-support core-themes-support core-display-init core-jump core-release-management core-custom-settings core-configuration-layer eieio-compat core-spacemacs-buffer core-funcs core-dotspacemacs ht cl help-mode warnings package url-handlers url-parse auth-source cl-seq password-cache url-vars seq eieio byte-opt bytecomp byte-compile cconv eieio-core eieio-loaddefs epg epg-config core-command-line pcase core-debug edmacro kmacro derived cl-macs gv advice profiler easymenu cl-loaddefs cl-lib page-break-lines easy-mmode core-emacs-backports subr-x time-date tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type 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 elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic 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 charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote kqueue cocoa ns lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 1411209 431571) (symbols 48 82837 1) (miscs 40 2876 4265) (strings 32 311225 33216) (string-bytes 1 10567800) (vectors 16 139011) (vector-slots 8 3139062 163364) (floats 8 1044 1162) (intervals 56 22198 2513) (buffers 992 77)) ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-04 17:38 bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized Aaron Jensen @ 2018-03-04 20:27 ` Alan Third 2018-03-04 21:34 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-04 20:27 UTC (permalink / raw) To: Aaron Jensen; +Cc: 30699 On Sun, Mar 04, 2018 at 09:38:27AM -0800, Aaron Jensen wrote: > It appears that (on macOS, at least) when a frame is resized, there is > an unsightly flicker. It does not matter if the frame is undecorated or > not. Simpler repro: (dotimes (n 10) (set-frame-parameter nil 'width (+ 80 n)) (sit-for 0.1)) -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-04 20:27 ` Alan Third @ 2018-03-04 21:34 ` Alan Third 2018-03-05 2:06 ` Aaron Jensen 2018-03-05 7:55 ` Aaron Jensen 0 siblings, 2 replies; 43+ messages in thread From: Alan Third @ 2018-03-04 21:34 UTC (permalink / raw) To: Aaron Jensen; +Cc: 30699 [-- Attachment #1: Type: text/plain, Size: 1338 bytes --] On Sun, Mar 04, 2018 at 08:27:36PM +0000, Alan Third wrote: > On Sun, Mar 04, 2018 at 09:38:27AM -0800, Aaron Jensen wrote: > > It appears that (on macOS, at least) when a frame is resized, there is > > an unsightly flicker. It does not matter if the frame is undecorated or > > not. > > Simpler repro: > > (dotimes (n 10) > (set-frame-parameter nil 'width (+ 80 n)) > (sit-for 0.1)) > It’s the call to SET_FRAME_GARBAGED in EmacsView::updateFrameSize. I don’t know if it’s needed in this circumstance, but without it it stops the frame being blanked when resizing with the mouse, which is unpleasant. The attached patch appears to fix it without breaking mouse resizing, but it looks like this comment in windowDidResize also counts for macOS: /* In GNUstep, at least currently, it's possible to get a didResize without getting a willResize.. therefore we need to act as if we got the willResize now */ I honestly don’t see that it makes any difference though. The root problem is actually that we’re unable to execute redisplay while the frame is being resized by a mouse. The NS event loop goes into some ‘modal’ state which we can’t break out of, thus preventing us from doing anything until it’s done. If that didn’t happen we wouldn’t need to blank the screen at all. -- Alan Third [-- Attachment #2: 0001-Fix-flicker-when-resizing-frame-on-macOS-bug-30699.patch --] [-- Type: text/plain, Size: 1380 bytes --] From 98c34098dca670b0613c84af347f4fa7046ae942 Mon Sep 17 00:00:00 2001 From: Alan Third <alan@idiocy.org> Date: Sun, 4 Mar 2018 21:29:21 +0000 Subject: [PATCH] Fix flicker when resizing frame on macOS (bug#30699) * src/nsterm.m (EmacsView::updateFrameSize): Remove SET_FRAME_GARBAGED call. (EmacsView::windoWillResize): Call SET_FRAME_GARBAGED here instead. --- src/nsterm.m | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/nsterm.m b/src/nsterm.m index 1919c6defa..719db4d552 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -6998,7 +6998,6 @@ - (void) updateFrameSize: (BOOL) delay FRAME_PIXEL_TO_TEXT_WIDTH (emacsframe, neww), FRAME_PIXEL_TO_TEXT_HEIGHT (emacsframe, newh), 0, delay, 0, 1); - SET_FRAME_GARBAGED (emacsframe); cancel_mouse_face (emacsframe); /* The next two lines set the frame to the same size as we've @@ -7119,6 +7118,12 @@ - (NSSize)windowWillResize: (NSWindow *)sender toSize: (NSSize)frameSize } } + /* When the frame is being resized with the mouse we need to blank + it out or else we end up with old stuff being displayed. + + FIXME: This may not be the place to put this (bug#30699). */ + SET_FRAME_GARBAGED (emacsframe); + NSTRACE_RETURN_SIZE (frameSize); return frameSize; -- 2.16.1 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-04 21:34 ` Alan Third @ 2018-03-05 2:06 ` Aaron Jensen 2018-03-05 3:27 ` Eli Zaretskii 2018-03-05 7:55 ` Aaron Jensen 1 sibling, 1 reply; 43+ messages in thread From: Aaron Jensen @ 2018-03-05 2:06 UTC (permalink / raw) To: Alan Third; +Cc: 30699 On Sun, Mar 4, 2018 at 1:34 PM, Alan Third <alan@idiocy.org> wrote: >> Simpler repro: >> >> (dotimes (n 10) >> (set-frame-parameter nil 'width (+ 80 n)) >> (sit-for 0.1)) >> Thank you, that's much easier :) > The attached patch appears to fix it without breaking mouse resizing, > but it looks like this comment in windowDidResize also counts for macOS: This patch appears to fix it for me, it's much nicer, thank you! I tested it with my keyboard resizing and mouse resizing and all seems to work well. Is this too dangerous of a patch to apply to emacs-26? The main case I'd make for it is these new posframe libraries are really nice, so it'd be nice for non-HEAD users to be able to use them w/o the flicker. Thanks! ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 2:06 ` Aaron Jensen @ 2018-03-05 3:27 ` Eli Zaretskii 2018-03-05 5:21 ` Aaron Jensen 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-05 3:27 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30699 > From: Aaron Jensen <aaronjensen@gmail.com> > Date: Sun, 4 Mar 2018 18:06:13 -0800 > Cc: 30699@debbugs.gnu.org > > Is this too dangerous of a patch to apply to emacs-26? The main case > I'd make for it is these new posframe libraries are really nice, so > it'd be nice for non-HEAD users to be able to use them w/o the > flicker. Not only is this too risky for emacs-26, I believe this change might cause regressions elsewhere, in the form of leaving portions of the frame not redrawn when needed. I suggest you run with this change for a few weeks and watch for redisplay problems, before concluding it's okay to install it. Thanks. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 3:27 ` Eli Zaretskii @ 2018-03-05 5:21 ` Aaron Jensen 2018-03-05 16:01 ` Eli Zaretskii 0 siblings, 1 reply; 43+ messages in thread From: Aaron Jensen @ 2018-03-05 5:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, 30699 On Sun, Mar 4, 2018 at 7:27 PM, Eli Zaretskii <eliz@gnu.org> wrote: > Not only is this too risky for emacs-26, I believe this change might > cause regressions elsewhere, in the form of leaving portions of the > frame not redrawn when needed. I suggest you run with this change for > a few weeks and watch for redisplay problems, before concluding it's > okay to install it. Interesting. I'll keep an eye out. Are there particular scenarios you have in mind that may trigger the issues? ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 5:21 ` Aaron Jensen @ 2018-03-05 16:01 ` Eli Zaretskii 2018-03-05 16:21 ` Aaron Jensen 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-05 16:01 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30699 > From: Aaron Jensen <aaronjensen@gmail.com> > Date: Sun, 4 Mar 2018 21:21:54 -0800 > Cc: Alan Third <alan@idiocy.org>, 30699@debbugs.gnu.org > > On Sun, Mar 4, 2018 at 7:27 PM, Eli Zaretskii <eliz@gnu.org> wrote: > > Not only is this too risky for emacs-26, I believe this change might > > cause regressions elsewhere, in the form of leaving portions of the > > frame not redrawn when needed. I suggest you run with this change for > > a few weeks and watch for redisplay problems, before concluding it's > > okay to install it. > > Interesting. I'll keep an eye out. Are there particular scenarios you > have in mind that may trigger the issues? Not really. Setting the frame's garbaged flag causes a thorough redisplay on the next opportunity, so removing that could prevent redisplay in a variety of situations. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 16:01 ` Eli Zaretskii @ 2018-03-05 16:21 ` Aaron Jensen 2018-03-05 18:00 ` Eli Zaretskii 0 siblings, 1 reply; 43+ messages in thread From: Aaron Jensen @ 2018-03-05 16:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, 30699 On Mon, Mar 5, 2018 at 8:01 AM, Eli Zaretskii <eliz@gnu.org> wrote: > Not really. Setting the frame's garbaged flag causes a thorough > redisplay on the next opportunity, so removing that could prevent > redisplay in a variety of situations. Ok, and because this removes the setting of the frame's garbage flag from the `updateFrameSize` function and moves it to when it receives the `windowWillResize` event, I should only expect to see painting issues after a frame's size is changed I would imagine. Does anyone know if there are more ways to change a frame's size than `set-frame-parameter`, a mouse drag or AppleScript? > AFAIK, no. Redrawing a garbaged frame involves clearing it and > completely redrawing all of its windows, and that is what you perceive > as flicker. Thanks, I was thinking about double buffering--painting both the clear and the next paint on the same buffer before swapping it in, but I'm sure that's much more simplistic than what is actually happening. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 16:21 ` Aaron Jensen @ 2018-03-05 18:00 ` Eli Zaretskii 2018-03-05 19:23 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-05 18:00 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30699 > From: Aaron Jensen <aaronjensen@gmail.com> > Date: Mon, 5 Mar 2018 08:21:45 -0800 > Cc: Alan Third <alan@idiocy.org>, 30699@debbugs.gnu.org > > > AFAIK, no. Redrawing a garbaged frame involves clearing it and > > completely redrawing all of its windows, and that is what you perceive > > as flicker. > > Thanks, I was thinking about double buffering--painting both the clear > and the next paint on the same buffer before swapping it in, but I'm > sure that's much more simplistic than what is actually happening. We already have double-buffering on X, perhaps it can be implemented on macOS as well. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 18:00 ` Eli Zaretskii @ 2018-03-05 19:23 ` Alan Third 2018-03-05 19:53 ` Eli Zaretskii 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-05 19:23 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, Aaron Jensen On Mon, Mar 05, 2018 at 08:00:07PM +0200, Eli Zaretskii wrote: > > From: Aaron Jensen <aaronjensen@gmail.com> > > Date: Mon, 5 Mar 2018 08:21:45 -0800 > > Cc: Alan Third <alan@idiocy.org>, 30699@debbugs.gnu.org > > > > > AFAIK, no. Redrawing a garbaged frame involves clearing it and > > > completely redrawing all of its windows, and that is what you perceive > > > as flicker. > > > > Thanks, I was thinking about double buffering--painting both the clear > > and the next paint on the same buffer before swapping it in, but I'm > > sure that's much more simplistic than what is actually happening. > > We already have double-buffering on X, perhaps it can be implemented > on macOS as well. We could do something similar using NSDisableScreenUpdates and NSEnableScreenUpdates: https://developer.apple.com/documentation/appkit/1473676-nsdisablescreenupdates?language=objc We should be able to wrap it round redisplay. Where would that be done? -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 19:23 ` Alan Third @ 2018-03-05 19:53 ` Eli Zaretskii 2018-03-06 22:55 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-05 19:53 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Mon, 5 Mar 2018 19:23:31 +0000 > From: Alan Third <alan@idiocy.org> > Cc: Aaron Jensen <aaronjensen@gmail.com>, 30699@debbugs.gnu.org > > > We already have double-buffering on X, perhaps it can be implemented > > on macOS as well. > > We could do something similar using NSDisableScreenUpdates and > NSEnableScreenUpdates: > > https://developer.apple.com/documentation/appkit/1473676-nsdisablescreenupdates?language=objc > > We should be able to wrap it round redisplay. Where would that be > done? I don't think I understand the meaning of "wrap it round redisplay" to answer that. Is the feature you mention significantly different from what we use for double-buffering on X? If not, you can use the same model. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 19:53 ` Eli Zaretskii @ 2018-03-06 22:55 ` Alan Third 2018-03-07 17:26 ` Eli Zaretskii 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-06 22:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen On Mon, Mar 05, 2018 at 09:53:37PM +0200, Eli Zaretskii wrote: > > Date: Mon, 5 Mar 2018 19:23:31 +0000 > > From: Alan Third <alan@idiocy.org> > > Cc: Aaron Jensen <aaronjensen@gmail.com>, 30699@debbugs.gnu.org > > > > > We already have double-buffering on X, perhaps it can be implemented > > > on macOS as well. > > > > We could do something similar using NSDisableScreenUpdates and > > NSEnableScreenUpdates: > > > > https://developer.apple.com/documentation/appkit/1473676-nsdisablescreenupdates?language=objc > > > > We should be able to wrap it round redisplay. Where would that be > > done? > > I don't think I understand the meaning of "wrap it round redisplay" to > answer that. Is the feature you mention significantly different from > what we use for double-buffering on X? If not, you can use the same > model. I don’t know how we handle double buffering on X, but if it’s anything like my previous experiences of double buffering, this is different. NS already uses double buffering, the issue here is that we want the screen blank and subsequent drawing of the frame to appear as one atomic action, but right now we see them as two actions. In theory if you call NSDisableScreenUpdates before the blanking of the frame, then call NSEnableScreenUpdates after drawing the contents of the frame, both should appear as one action (we don’t see the blank frame at all). I’ve tried adding calls to NSDisableScreenUpdates and NSEnableScreenUpdates in redisplay_internal, just to see if it works, but I couldn’t get it to work at all: I always saw the blanked frame. Either these functions don’t work as advertised or there’s something else going on. It’s quite probable I’ve misunderstood redisplay_internal. -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-06 22:55 ` Alan Third @ 2018-03-07 17:26 ` Eli Zaretskii 2018-03-07 20:26 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-07 17:26 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Tue, 6 Mar 2018 22:55:02 +0000 > From: Alan Third <alan@idiocy.org> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > In theory if you call NSDisableScreenUpdates before the blanking of > the frame, then call NSEnableScreenUpdates after drawing the contents > of the frame, both should appear as one action (we don’t see the blank > frame at all). Where does the frame blanking happen in the NS build? > I’ve tried adding calls to NSDisableScreenUpdates and > NSEnableScreenUpdates in redisplay_internal, just to see if it works, > but I couldn’t get it to work at all: I always saw the blanked frame. > Either these functions don’t work as advertised or there’s something > else going on. It’s quite probable I’ve misunderstood > redisplay_internal. If you tell me where did you try to add these calls and perhaps also what was your mental model of what redisplay_internal does when you did that, I might be able to help you add this in the right places (assuming the idea is workable, and I trust your expertise on that). ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-07 17:26 ` Eli Zaretskii @ 2018-03-07 20:26 ` Alan Third 2018-03-08 19:15 ` Eli Zaretskii 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-07 20:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen On Wed, Mar 07, 2018 at 07:26:01PM +0200, Eli Zaretskii wrote: > > I’ve tried adding calls to NSDisableScreenUpdates and > > NSEnableScreenUpdates in redisplay_internal, just to see if it works, > > but I couldn’t get it to work at all: I always saw the blanked frame. > > Either these functions don’t work as advertised or there’s something > > else going on. It’s quite probable I’ve misunderstood > > redisplay_internal. > > If you tell me where did you try to add these calls and perhaps also > what was your mental model of what redisplay_internal does when you > did that, I might be able to help you add this in the right places > (assuming the idea is workable, and I trust your expertise on that). updateFrameSize in nsterm.m calls SET_FRAME_GARBAGED, which appears to just flag the frame for clearing. My assumption was that redisplay first checks if the frame is garbaged and if so clears it, then redraws the contents of the frame. I put the calls to NS(En|Dis)ableScreenUpdates at the start and end of redisplay_internal: modified src/xdisp.c @@ -13868,7 +13868,7 @@ redisplay_internal (void) redisplaying_p = true; block_buffer_flips (); specbind (Qinhibit_free_realized_faces, Qnil); - + ns_disable_screen_updates (); /* Record this function, so it appears on the profiler's backtraces. */ record_in_backtrace (Qredisplay_internal_xC_functionx, 0, 0); @@ -14602,7 +14602,7 @@ redisplay_internal (void) #endif if (interrupt_input && interrupts_deferred) request_sigio (); - + ns_enable_screen_updates (); unbind_to (count, Qnil); RESUME_POLLING; } I realise this isn’t robust, but I was just testing it out. I imagine my failure here is that ns_clear_frame isn’t called from redisplay at all, but somewhere else. -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-07 20:26 ` Alan Third @ 2018-03-08 19:15 ` Eli Zaretskii 2018-03-09 12:09 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-08 19:15 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Wed, 7 Mar 2018 20:26:03 +0000 > From: Alan Third <alan@idiocy.org> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > updateFrameSize in nsterm.m calls SET_FRAME_GARBAGED, which appears to > just flag the frame for clearing. > > My assumption was that redisplay first checks if the frame is garbaged > and if so clears it, then redraws the contents of the frame. > > I put the calls to NS(En|Dis)ableScreenUpdates at the start and end of > redisplay_internal: > > modified src/xdisp.c > @@ -13868,7 +13868,7 @@ redisplay_internal (void) > redisplaying_p = true; > block_buffer_flips (); > specbind (Qinhibit_free_realized_faces, Qnil); > - > + ns_disable_screen_updates (); > /* Record this function, so it appears on the profiler's backtraces. */ > record_in_backtrace (Qredisplay_internal_xC_functionx, 0, 0); > > @@ -14602,7 +14602,7 @@ redisplay_internal (void) > #endif > if (interrupt_input && interrupts_deferred) > request_sigio (); > - > + ns_enable_screen_updates (); > unbind_to (count, Qnil); > RESUME_POLLING; > } > > I realise this isn’t robust, but I was just testing it out. > > I imagine my failure here is that ns_clear_frame isn’t called from > redisplay at all, but somewhere else. I believe it is called from clear_frame, which is called by redraw_frame, which in turn is called by redraw_garbaged_frames. The call to ns_enable_screen_updates is too late, I think: you must enable screen updates before redisplay_internal calls update_frame, because that's where we actually draw stuff on the screen. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-08 19:15 ` Eli Zaretskii @ 2018-03-09 12:09 ` Alan Third 2018-03-09 13:32 ` Eli Zaretskii 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-09 12:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen On Thu, Mar 08, 2018 at 09:15:37PM +0200, Eli Zaretskii wrote: > > Date: Wed, 7 Mar 2018 20:26:03 +0000 > > From: Alan Third <alan@idiocy.org> > > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > > > updateFrameSize in nsterm.m calls SET_FRAME_GARBAGED, which appears to > > just flag the frame for clearing. I *finally* worked out what’s going on here. After updateFrameSize is called we end up in x_set_window_size: [window setFrame: wr display: YES]; That resizes and blanks the frame, then asks it to redraw, which takes us, eventually, to drawRect, which does: ns_clear_frame_area (emacsframe, x, y, width, height); block_input (); expose_frame (emacsframe, x, y, width, height); unblock_input (); ns_clear_frame_area does nothing here because the frame is already blank, and expose_frame doesn’t redraw anything because the first thing it does is: /* No need to redraw if frame will be redrawn soon. */ if (FRAME_GARBAGED_P (f)) { TRACE ((stderr, " garbaged\n")); return; } SO, I think that the SET_GARBAGED_FRAME call in updateFrameSize is premature, which probably means my original patch is (surprisingly) the correct fix. Possibly with the addition of SET_GARBAGED_FRAME after the call to setFrame in x_set_window_size, although it makes no obvious difference here. -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-09 12:09 ` Alan Third @ 2018-03-09 13:32 ` Eli Zaretskii 2018-03-09 23:24 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-09 13:32 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Fri, 9 Mar 2018 12:09:52 +0000 > From: Alan Third <alan@idiocy.org> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > [window setFrame: wr display: YES]; > > That resizes and blanks the frame, then asks it to redraw, which takes > us, eventually, to drawRect, which does: > > ns_clear_frame_area (emacsframe, x, y, width, height); > block_input (); > expose_frame (emacsframe, x, y, width, height); > unblock_input (); > > ns_clear_frame_area does nothing here because the frame is already > blank, and expose_frame doesn’t redraw anything because the first > thing it does is: > > /* No need to redraw if frame will be redrawn soon. */ > if (FRAME_GARBAGED_P (f)) > { > TRACE ((stderr, " garbaged\n")); > return; > } > > SO, I think that the SET_GARBAGED_FRAME call in updateFrameSize is > premature, which probably means my original patch is (surprisingly) > the correct fix. But then what would that fix solve? The above test in expose_frame is not a bug: if the frame is marked as garbaged (and it must be after resizing it), then the call to expose_frame cannot possibly DTRT, so it exits right away without doing anything. We should enter redisplay soon enough, which will redraw the entire frame. If anything, then the call to expose_frame in the control flow that reacts to frame resizing is the one that should be removed, because it's bound to do nothing useful. If removing SET_FRAME_GARBAGED when the frame is resized seems to solve some problem, then you are likely not really resizing the frame, or not resizing it significantly enough to show why SET_FRAME_GARBAGED is really needed. Or maybe I'm just missing something. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-09 13:32 ` Eli Zaretskii @ 2018-03-09 23:24 ` Alan Third 2018-03-10 0:25 ` Alan Third 2018-03-10 8:15 ` Eli Zaretskii 0 siblings, 2 replies; 43+ messages in thread From: Alan Third @ 2018-03-09 23:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen On Fri, Mar 09, 2018 at 03:32:09PM +0200, Eli Zaretskii wrote: > > Date: Fri, 9 Mar 2018 12:09:52 +0000 > > From: Alan Third <alan@idiocy.org> > > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > > > SO, I think that the SET_GARBAGED_FRAME call in updateFrameSize is > > premature, which probably means my original patch is (surprisingly) > > the correct fix. > > But then what would that fix solve? The above test in expose_frame is > not a bug: if the frame is marked as garbaged (and it must be after > resizing it), then the call to expose_frame cannot possibly DTRT, so > it exits right away without doing anything. We should enter redisplay > soon enough, which will redraw the entire frame. If anything, then > the call to expose_frame in the control flow that reacts to frame > resizing is the one that should be removed, because it's bound to do > nothing useful. > > If removing SET_FRAME_GARBAGED when the frame is resized seems to > solve some problem, then you are likely not really resizing the frame, > or not resizing it significantly enough to show why SET_FRAME_GARBAGED > is really needed. > > Or maybe I'm just missing something. When the window manager resizes the frame it blanks its contents out. This results in a flicker as the full redisplay only happens after the user sees the blanked frame. Removing, or moving, SET_FRAME_GARBAGED allows the frame contents to be redrawn before the user sees the blank frame. What’s displayed is not correct but it’s shown for such a short time that it’s not noticable, at least on my machine, and there is no flicker. It’s not a perfect solution, but it’s better than what we have at the moment, IMO. The other solution I have is to use NSDisableScreenUpdates to prevent updates being flushed to the screen until after redisplay, but that completely breaks resizing with the mouse. If redisplay was able to run during interactive resizing with the mouse then this would work, but that seems to require the NS code to run in its own thread, which looks difficult to implement. -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-09 23:24 ` Alan Third @ 2018-03-10 0:25 ` Alan Third 2018-03-10 1:18 ` Aaron Jensen 2018-03-10 8:30 ` Eli Zaretskii 2018-03-10 8:15 ` Eli Zaretskii 1 sibling, 2 replies; 43+ messages in thread From: Alan Third @ 2018-03-10 0:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen [-- Attachment #1: Type: text/plain, Size: 638 bytes --] On Fri, Mar 09, 2018 at 11:24:15PM +0000, Alan Third wrote: > The other solution I have is to use NSDisableScreenUpdates to prevent > updates being flushed to the screen until after redisplay, but that > completely breaks resizing with the mouse. I just realised that this isn’t actually hard to get right. Patch attached. I think this is a better solution than the last one. Disabling screen updates just stops them being flushed to the screen, when they’re enabled all the updates happen at once (including the window manager’s frame resize). I guess it’s like drawing to an off‐screen buffer then swapping. -- Alan Third [-- Attachment #2: 0001-Fix-frame-resize-flicker-on-macOS-bug-30699.patch --] [-- Type: text/plain, Size: 2918 bytes --] From c382338d44c3ff833e965e1d92106a90b75edec5 Mon Sep 17 00:00:00 2001 From: Alan Third <alan@idiocy.org> Date: Sat, 10 Mar 2018 00:09:09 +0000 Subject: [PATCH] Fix frame resize flicker on macOS (bug#30699) * src/nsterm.h (ns_enable_screen_updates): New function. * src/nsterm.m (ns_enable_screen_updates): (ns_disable_screen_updates): New functions. (disable_screen_updates_count): Count of number of times we've called NSDisableScreenUpdates. (x_set_window_size): Disable screen updates when not in a live resize loop. * src/xdisp.c (redisplay_internal): Reenable NS screenupdates at end of redisplay. --- src/nsterm.h | 3 +++ src/nsterm.m | 30 ++++++++++++++++++++++++++++++ src/xdisp.c | 3 +++ 3 files changed, 36 insertions(+) diff --git a/src/nsterm.h b/src/nsterm.h index 8b985930ec..df59a7dbd9 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1160,6 +1160,9 @@ extern void ns_release_autorelease_pool (void *); extern const char *ns_get_defaults_value (const char *key); extern void ns_init_locale (void); +#ifdef NS_IMPL_COCOA +extern void ns_enable_screen_updates (void); +#endif /* in nsmenu */ extern void update_frame_tool_bar (struct frame *f); diff --git a/src/nsterm.m b/src/nsterm.m index 1919c6defa..b4ec384aaf 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -288,6 +288,7 @@ - (NSColor *)colorUsingDefaultColorSpace static BOOL ns_fake_keydown = NO; #ifdef NS_IMPL_COCOA static BOOL ns_menu_bar_is_hidden = NO; +static int disable_screen_updates_count = 0; #endif /*static int debug_lock = 0; */ @@ -727,6 +728,26 @@ Free a pool and temporary objects it refers to (callable from C) } +#ifdef NS_IMPL_COCOA +static void +ns_disable_screen_updates (void) +{ + NSDisableScreenUpdates (); + disable_screen_updates_count++; +} + +void +ns_enable_screen_updates (void) +{ + while (disable_screen_updates_count > 0) + { + NSEnableScreenUpdates (); + disable_screen_updates_count--; + } +} +#endif + + static BOOL ns_menu_bar_should_be_hidden (void) /* True, if the menu bar should be hidden. */ @@ -1877,6 +1898,15 @@ -(void)remove block_input (); +#ifdef NS_IMPL_COCOA + /* To prevent showing the user a blank frame, stop updates being + flushed to the screen until after redisplay has completed. This + breaks live resize (resizing with a mouse), so don't do it if + we're in a live resize loop. */ + if (![view inLiveResize]) + ns_disable_screen_updates (); +#endif + if (pixelwise) { pixelwidth = FRAME_TEXT_TO_PIXEL_WIDTH (f, width); diff --git a/src/xdisp.c b/src/xdisp.c index 9170d6b777..d4fdb44b32 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -14599,6 +14599,9 @@ redisplay_internal (void) end_of_redisplay: #ifdef HAVE_NS ns_set_doc_edited (); +#ifdef NS_IMPL_COCOA + ns_enable_screen_updates (); +#endif #endif if (interrupt_input && interrupts_deferred) request_sigio (); -- 2.16.1 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-10 0:25 ` Alan Third @ 2018-03-10 1:18 ` Aaron Jensen 2018-03-10 8:30 ` Eli Zaretskii 1 sibling, 0 replies; 43+ messages in thread From: Aaron Jensen @ 2018-03-10 1:18 UTC (permalink / raw) To: Alan Third; +Cc: 30699 On Fri, Mar 9, 2018 at 4:25 PM, Alan Third <alan@idiocy.org> wrote: > Patch attached. I think this is a better solution than the last one. This works for me. Thank you! ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-10 0:25 ` Alan Third 2018-03-10 1:18 ` Aaron Jensen @ 2018-03-10 8:30 ` Eli Zaretskii 2018-03-10 23:07 ` Alan Third 1 sibling, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-10 8:30 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Sat, 10 Mar 2018 00:25:55 +0000 > From: Alan Third <alan@idiocy.org> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > diff --git a/src/nsterm.m b/src/nsterm.m > index 1919c6defa..b4ec384aaf 100644 > --- a/src/nsterm.m > +++ b/src/nsterm.m > @@ -288,6 +288,7 @@ - (NSColor *)colorUsingDefaultColorSpace > static BOOL ns_fake_keydown = NO; > #ifdef NS_IMPL_COCOA > static BOOL ns_menu_bar_is_hidden = NO; > +static int disable_screen_updates_count = 0; Doesn't making this static mean potential trouble if redisplay is run from a non-main thread? > diff --git a/src/xdisp.c b/src/xdisp.c > index 9170d6b777..d4fdb44b32 100644 > --- a/src/xdisp.c > +++ b/src/xdisp.c > @@ -14599,6 +14599,9 @@ redisplay_internal (void) > end_of_redisplay: > #ifdef HAVE_NS > ns_set_doc_edited (); > +#ifdef NS_IMPL_COCOA > + ns_enable_screen_updates (); > +#endif > #endif Can x_set_window_size be called only from redisplay_internal? If not, doesn't this risk leaving the updates disabled, if x_set_window_size is called from some other place? Also, redisplay_internal has a few early returns which don't go through end_of_redisplay -- are you sure they can never happen in this situation? For example, what if popup_activated returns non-zero? Finally, this code needs comments that explain why this is done. Thanks. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-10 8:30 ` Eli Zaretskii @ 2018-03-10 23:07 ` Alan Third 2018-03-11 16:29 ` Eli Zaretskii 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-10 23:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen On Sat, Mar 10, 2018 at 10:30:27AM +0200, Eli Zaretskii wrote: > > Date: Sat, 10 Mar 2018 00:25:55 +0000 > > From: Alan Third <alan@idiocy.org> > > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > > > diff --git a/src/nsterm.m b/src/nsterm.m > > index 1919c6defa..b4ec384aaf 100644 > > --- a/src/nsterm.m > > +++ b/src/nsterm.m > > @@ -288,6 +288,7 @@ - (NSColor *)colorUsingDefaultColorSpace > > static BOOL ns_fake_keydown = NO; > > #ifdef NS_IMPL_COCOA > > static BOOL ns_menu_bar_is_hidden = NO; > > +static int disable_screen_updates_count = 0; > > Doesn't making this static mean potential trouble if redisplay is run > from a non-main thread? I’m not aware of any problems with global static variables, but I’m certainly no expert. What is the risk? > > diff --git a/src/xdisp.c b/src/xdisp.c > > index 9170d6b777..d4fdb44b32 100644 > > --- a/src/xdisp.c > > +++ b/src/xdisp.c > > @@ -14599,6 +14599,9 @@ redisplay_internal (void) > > end_of_redisplay: > > #ifdef HAVE_NS > > ns_set_doc_edited (); > > +#ifdef NS_IMPL_COCOA > > + ns_enable_screen_updates (); > > +#endif > > #endif > > Can x_set_window_size be called only from redisplay_internal? If not, > doesn't this risk leaving the updates disabled, if x_set_window_size > is called from some other place? No, I believe it’s never called from redisplay_internal. But x_set_window_size always leaves the frame blank (and there’s no way round that as far as I can see), so there’s not much risk in disabling screen updates until redisplay completes. All we’re doing is preventing the user from seeing a blank frame. Or is there some way for the frame to be redrawn other than redisplay or expose_frame? > Also, redisplay_internal has a few early returns which don't go > through end_of_redisplay -- are you sure they can never happen in this > situation? For example, what if popup_activated returns non-zero? Nope. Is there a better place to put it? For example is there a hook that runs when redisplay exits? -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-10 23:07 ` Alan Third @ 2018-03-11 16:29 ` Eli Zaretskii 2018-03-12 0:46 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-11 16:29 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Sat, 10 Mar 2018 23:07:06 +0000 > From: Alan Third <alan@idiocy.org> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > > > +static int disable_screen_updates_count = 0; > > > > Doesn't making this static mean potential trouble if redisplay is run > > from a non-main thread? > > I’m not aware of any problems with global static variables, but I’m > certainly no expert. What is the risk? That one thread sets the variable, and another tries to use the value, believing that it was set by that other thread. > > Can x_set_window_size be called only from redisplay_internal? If not, > > doesn't this risk leaving the updates disabled, if x_set_window_size > > is called from some other place? > > No, I believe it’s never called from redisplay_internal. Then how do we guarantee that these two calls, one from x_set_window_size, the other from redisplay_internal, will be balanced, and you never end up with screen updates disabled when you don't intend? > But x_set_window_size always leaves the frame blank (and there’s no > way round that as far as I can see), so there’s not much risk in > disabling screen updates until redisplay completes. All we’re doing is > preventing the user from seeing a blank frame. The question is: can x_set_window_size be called without a redisplay happening soon enough, e.g. if Emacs is busy doing some lengthy calculation? > > Also, redisplay_internal has a few early returns which don't go > > through end_of_redisplay -- are you sure they can never happen in this > > situation? For example, what if popup_activated returns non-zero? > > Nope. Is there a better place to put it? For example is there a hook > that runs when redisplay exits? Unless I'm misremembering, I don't think there is such a hook. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-11 16:29 ` Eli Zaretskii @ 2018-03-12 0:46 ` Alan Third 2018-03-12 16:39 ` Eli Zaretskii 2018-03-13 15:34 ` Aaron Jensen 0 siblings, 2 replies; 43+ messages in thread From: Alan Third @ 2018-03-12 0:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen On Sun, Mar 11, 2018 at 06:29:05PM +0200, Eli Zaretskii wrote: > > Date: Sat, 10 Mar 2018 23:07:06 +0000 > > From: Alan Third <alan@idiocy.org> > > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > > > > Can x_set_window_size be called only from redisplay_internal? If not, > > > doesn't this risk leaving the updates disabled, if x_set_window_size > > > is called from some other place? > > > > No, I believe it’s never called from redisplay_internal. > > Then how do we guarantee that these two calls, one from > x_set_window_size, the other from redisplay_internal, will be > balanced, and you never end up with screen updates disabled when you > don't intend? > > > But x_set_window_size always leaves the frame blank (and there’s no > > way round that as far as I can see), so there’s not much risk in > > disabling screen updates until redisplay completes. All we’re doing is > > preventing the user from seeing a blank frame. > > The question is: can x_set_window_size be called without a redisplay > happening soon enough, e.g. if Emacs is busy doing some lengthy > calculation? OK, so this plan is a non‐starter. Can I check an assumption I’m making? Am I able to call redisplay whenever I want? That is, does calling it ever result in a longjmp? -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-12 0:46 ` Alan Third @ 2018-03-12 16:39 ` Eli Zaretskii 2018-03-12 23:42 ` Alan Third 2018-03-13 15:34 ` Aaron Jensen 1 sibling, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-12 16:39 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Mon, 12 Mar 2018 00:46:38 +0000 > From: Alan Third <alan@idiocy.org> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > Am I able to call redisplay whenever I want? Not sure about "whenever I want" part. > That is, does calling it ever result in a longjmp? I think it never longjmps, even on TTYs, where C-g generates SIGINT. But I may be wrong here. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-12 16:39 ` Eli Zaretskii @ 2018-03-12 23:42 ` Alan Third 2018-03-13 12:19 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-12 23:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen On Mon, Mar 12, 2018 at 06:39:59PM +0200, Eli Zaretskii wrote: > > Date: Mon, 12 Mar 2018 00:46:38 +0000 > > From: Alan Third <alan@idiocy.org> > > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > > > That is, does calling [redisplay] ever result in a longjmp? > > I think it never longjmps, even on TTYs, where C-g generates SIGINT. > But I may be wrong here. So would it be acceptable to just call redisplay after the resize? modified src/nsterm.m @@ -7007,6 +7007,7 @@ - (void) updateFrameSize: (BOOL) delay to be a noop. (bug#28872) */ wr = NSMakeRect (0, 0, neww, newh); [view setFrame: wr]; + redisplay (); // to do: consider using [NSNotificationCenter postNotificationName:]. [self windowDidMove: // Update top/left. This seems far too easy, so I’m sure there must be some reason it can’t work correctly. This code can only run on the main thread, if that’s a concern. -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-12 23:42 ` Alan Third @ 2018-03-13 12:19 ` Alan Third 2018-03-13 16:56 ` Eli Zaretskii 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-13 12:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen On Mon, Mar 12, 2018 at 11:42:39PM +0000, Alan Third wrote: > So would it be acceptable to just call redisplay after the resize? > > modified src/nsterm.m > @@ -7007,6 +7007,7 @@ - (void) updateFrameSize: (BOOL) delay > to be a noop. (bug#28872) */ > wr = NSMakeRect (0, 0, neww, newh); > [view setFrame: wr]; > + redisplay (); > > // to do: consider using [NSNotificationCenter postNotificationName:]. > [self windowDidMove: // Update top/left. Nah, forget it. I tried it and found an easily reproducible crash. I think the only solution left is to take a copy of the contents of the frame, resize, then copy the contents back. I don’t know how to do that and a quick google search reveals nothing helpful. Apple assume you’ll always be able to redraw the contents of the window on resize, afaict, so they don’t provide any way of retaining the pre‐resize contents. -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-13 12:19 ` Alan Third @ 2018-03-13 16:56 ` Eli Zaretskii 2018-03-13 20:18 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-13 16:56 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Tue, 13 Mar 2018 12:19:04 +0000 > From: Alan Third <alan@idiocy.org> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > I think the only solution left is to take a copy of the contents of > the frame, resize, then copy the contents back. I don’t know how to do > that and a quick google search reveals nothing helpful. What about the idea I brought up earlier: to avoid blanking the frame in this case (but still mark it garbaged)? ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-13 16:56 ` Eli Zaretskii @ 2018-03-13 20:18 ` Alan Third 0 siblings, 0 replies; 43+ messages in thread From: Alan Third @ 2018-03-13 20:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, Aaron Jensen [-- Attachment #1: Type: text/plain, Size: 672 bytes --] On Tue, 13 Mar 2018, 16:57 Eli Zaretskii, <eliz@gnu.org> wrote: > > Date: Tue, 13 Mar 2018 12:19:04 +0000 > > From: Alan Third <alan@idiocy.org> > > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > > > I think the only solution left is to take a copy of the contents of > > the frame, resize, then copy the contents back. I don’t know how to do > > that and a quick google search reveals nothing helpful. > > What about the idea I brought up earlier: to avoid blanking the frame > in this case (but still mark it garbaged)? > I don't see any way to avoid blanking it. Cocoa does it when the frame resizes and doesnt provide any option not to. > [-- Attachment #2: Type: text/html, Size: 1399 bytes --] ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-12 0:46 ` Alan Third 2018-03-12 16:39 ` Eli Zaretskii @ 2018-03-13 15:34 ` Aaron Jensen 2018-03-14 15:08 ` Alan Third 1 sibling, 1 reply; 43+ messages in thread From: Aaron Jensen @ 2018-03-13 15:34 UTC (permalink / raw) To: Alan Third; +Cc: 30699 mOn Sun, Mar 11, 2018 at 5:46 PM, Alan Third <alan@idiocy.org> wrote: >> The question is: can x_set_window_size be called without a redisplay >> happening soon enough, e.g. if Emacs is busy doing some lengthy >> calculation? > > OK, so this plan is a non‐starter. Were you able to find a place where x_set_window_size can be called w/o a redisplay happening soon enough? I haven't seen any glitches using this patch yet, fwiw. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-13 15:34 ` Aaron Jensen @ 2018-03-14 15:08 ` Alan Third 2018-03-19 15:15 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-14 15:08 UTC (permalink / raw) To: Aaron Jensen; +Cc: 30699 On Tue, Mar 13, 2018 at 08:34:10AM -0700, Aaron Jensen wrote: > mOn Sun, Mar 11, 2018 at 5:46 PM, Alan Third <alan@idiocy.org> wrote: > >> The question is: can x_set_window_size be called without a redisplay > >> happening soon enough, e.g. if Emacs is busy doing some lengthy > >> calculation? > > > > OK, so this plan is a non‐starter. > > Were you able to find a place where x_set_window_size can be called > w/o a redisplay happening soon enough? > > I haven't seen any glitches using this patch yet, fwiw. I haven’t come across anything yet, but I’ve not been using this patch much. Watch out for macOS re‐enabling screen updates after ~1 second. It does this automatically; I guess to stop buggy code from freezing the application completely. It should log a message to stderr when it does. If we are going to use this code, as Eli pointed out, I’ll have to catch every place where redisplay returns, so it’s not ready for prime‐time yet. -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-14 15:08 ` Alan Third @ 2018-03-19 15:15 ` Alan Third 2018-03-19 15:27 ` Eli Zaretskii 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-19 15:15 UTC (permalink / raw) To: Aaron Jensen; +Cc: 30699 [-- Attachment #1: Type: text/plain, Size: 1222 bytes --] On Wed, Mar 14, 2018 at 03:08:58PM +0000, Alan Third wrote: > On Tue, Mar 13, 2018 at 08:34:10AM -0700, Aaron Jensen wrote: > > > > I haven't seen any glitches using this patch yet, fwiw. > > I haven’t come across anything yet, but I’ve not been using this patch > much. > > Watch out for macOS re‐enabling screen updates after ~1 second. It > does this automatically; I guess to stop buggy code from freezing the > application completely. It turns out that even with screen updates disabled some calls still force the screen to update. I’m not sure which ones, but it does mean we’re unlikely to completely lock up Emacs with this. I’ve attached a new version of the patch. Eli, I left the global variable as static since as far as I can tell static global variables are still global to all threads, which is the behaviour I believe we want. These functions should only be called from the main thread anyway, Cocoa will kill the thread if GUI calls are made from non‐main threads. If it definitely shouldn’t be static, what should I do with it? I moved the call to ns_enable_screen_updates in unwind_redisplay as that’s where the double buffering code appears to unblock updates. -- Alan Third [-- Attachment #2: v2-0001-Fix-frame-resize-flicker-on-macOS-bug-30699.patch --] [-- Type: text/plain, Size: 4256 bytes --] From 823298202face05009808d2f00e2faa711c3882f Mon Sep 17 00:00:00 2001 From: Alan Third <alan@idiocy.org> Date: Sat, 10 Mar 2018 00:09:09 +0000 Subject: [PATCH v2] Fix frame resize flicker on macOS (bug#30699) * src/nsterm.h (ns_enable_screen_updates): New function. * src/nsterm.m (ns_enable_screen_updates): (ns_disable_screen_updates): New functions. (disable_screen_updates_count): Count of number of times we've called NSDisableScreenUpdates. (x_set_window_size): Disable screen updates when not in a live resize loop. * src/xdisp.c (redisplay_internal): Reenable screen updates when redisplay doesn't complete due to a popup. (unwind_redisplay): Reenable screen updates. --- src/nsterm.h | 3 +++ src/nsterm.m | 46 ++++++++++++++++++++++++++++++++++++++++++++++ src/xdisp.c | 16 +++++++++++++++- 3 files changed, 64 insertions(+), 1 deletion(-) diff --git a/src/nsterm.h b/src/nsterm.h index 8b985930ec..df59a7dbd9 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1160,6 +1160,9 @@ extern void ns_release_autorelease_pool (void *); extern const char *ns_get_defaults_value (const char *key); extern void ns_init_locale (void); +#ifdef NS_IMPL_COCOA +extern void ns_enable_screen_updates (void); +#endif /* in nsmenu */ extern void update_frame_tool_bar (struct frame *f); diff --git a/src/nsterm.m b/src/nsterm.m index 75e0b837c6..45367dd36f 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -288,6 +288,9 @@ - (NSColor *)colorUsingDefaultColorSpace static BOOL ns_fake_keydown = NO; #ifdef NS_IMPL_COCOA static BOOL ns_menu_bar_is_hidden = NO; + +/* The number of times NSDisableScreenUpdates has been called. */ +static int disable_screen_updates_count = 0; #endif /*static int debug_lock = 0; */ @@ -727,6 +730,40 @@ Free a pool and temporary objects it refers to (callable from C) } +#ifdef NS_IMPL_COCOA +/* Disabling screen updates can be used to make several actions appear + "atomic" to the end user. It seems some actions can still update + the display, though. + + When we re-enable screen updates the number of calls to + NSEnableScreenUpdates should match the number to + NSDisableScreenUpdates. + + We use this to prevent the user seeing a blank frame after it has + been resized. x_set_window_size disables updates and when + redisplay compeltes unwind_redisplay enables them again + (bug#30699). */ + +static void +ns_disable_screen_updates (void) +{ + NSDisableScreenUpdates (); + disable_screen_updates_count++; +} + +void +ns_enable_screen_updates (void) +/* Re-enable screen updates. Called from unwind_redisplay. */ +{ + while (disable_screen_updates_count > 0) + { + NSEnableScreenUpdates (); + disable_screen_updates_count--; + } +} +#endif + + static BOOL ns_menu_bar_should_be_hidden (void) /* True, if the menu bar should be hidden. */ @@ -1877,6 +1914,15 @@ -(void)remove block_input (); +#ifdef NS_IMPL_COCOA + /* To prevent showing the user a blank frame, stop updates being + flushed to the screen until after redisplay has completed. This + breaks live resize (resizing with a mouse), so don't do it if + we're in a live resize loop. */ + if (![view inLiveResize]) + ns_disable_screen_updates (); +#endif + if (pixelwise) { pixelwidth = FRAME_TEXT_TO_PIXEL_WIDTH (f, width); diff --git a/src/xdisp.c b/src/xdisp.c index a97d4db607..4778f532cd 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -13918,7 +13918,15 @@ redisplay_internal (void) #if defined (USE_X_TOOLKIT) || defined (USE_GTK) || defined (HAVE_NS) if (popup_activated ()) - return; + { +#ifdef NS_IMPL_COCOA + /* On macOS we may have disabled screen updates due to window + resizing. We should re-enable them so the popup can be + displayed. */ + ns_enable_screen_updates (); +#endif + return; + } #endif /* I don't think this happens but let's be paranoid. */ @@ -14722,6 +14730,12 @@ unwind_redisplay (void) { redisplaying_p = false; unblock_buffer_flips (); +#ifdef NS_IMPL_COCOA + /* On macOS we may have disabled screen updates due to window + resizing. When redisplay completes we want to re-enable + them. */ + ns_enable_screen_updates (); +#endif } -- 2.16.1 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-19 15:15 ` Alan Third @ 2018-03-19 15:27 ` Eli Zaretskii 2018-03-19 17:19 ` Alan Third 0 siblings, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-19 15:27 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Mon, 19 Mar 2018 15:15:52 +0000 > From: Alan Third <alan@idiocy.org> > Cc: Eli Zaretskii <eliz@gnu.org>, 30699@debbugs.gnu.org > > I’ve attached a new version of the patch. > > Eli, I left the global variable as static since as far as I can tell > static global variables are still global to all threads, which is the > behaviour I believe we want. These functions should only be called > from the main thread anyway, Cocoa will kill the thread if GUI calls > are made from non‐main threads. > > If it definitely shouldn’t be static, what should I do with it? > > I moved the call to ns_enable_screen_updates in unwind_redisplay as > that’s where the double buffering code appears to unblock updates. It's fine with me to install this on master, and see if there are any adverse effects. Thanks. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-19 15:27 ` Eli Zaretskii @ 2018-03-19 17:19 ` Alan Third 2018-03-20 21:50 ` Aaron Jensen 0 siblings, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-19 17:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30699, aaronjensen On Mon, Mar 19, 2018 at 05:27:42PM +0200, Eli Zaretskii wrote: > > Date: Mon, 19 Mar 2018 15:15:52 +0000 > > From: Alan Third <alan@idiocy.org> > > Cc: Eli Zaretskii <eliz@gnu.org>, 30699@debbugs.gnu.org > > > > I’ve attached a new version of the patch. > > > > It's fine with me to install this on master, and see if there are any > adverse effects. Pushed to master. Thanks. -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-19 17:19 ` Alan Third @ 2018-03-20 21:50 ` Aaron Jensen 2018-03-20 23:22 ` Aaron Jensen 2018-03-21 6:32 ` Eli Zaretskii 0 siblings, 2 replies; 43+ messages in thread From: Aaron Jensen @ 2018-03-20 21:50 UTC (permalink / raw) To: Alan Third; +Cc: 30699 I've been having crashes on master today. Here's the dump (I didn't have lldb attached at the time). Thread 5 is what pointed me to this: 3 com.apple.SkyLight 0x00007fff594c6b44 CGSUpdateManager::enable_update(unsigned long long) + 320 dump: Process: Emacs [24810] Path: /usr/local/Cellar/emacs-plus/HEAD-b39ca55/Emacs.app/Contents/MacOS/Emacs Identifier: org.gnu.Emacs Version: Version 27.0.50 (9.0) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: Emacs [24810] User ID: 501 Date/Time: 2018-03-20 14:46:41.959 -0700 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Bridge OS Version: 3.0 (14Y661) Anonymous UUID: 09E26AFE-B1D5-81E4-DFC1-FBBA35A17B93 Sleep/Wake UUID: FB6822D9-AAE9-44F2-93DF-F9B725B456CF Time Awake Since Boot: 250000 seconds Time Since Wake: 2400 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY VM Regions Near 0: --> __TEXT 0000000100000000-00000001001e0000 [ 1920K] r-x/rwx SM=COW ` [/usr/local/Cellar/emacs-plus/HEAD-b39ca55/Emacs.app/Contents/MacOS/Emacs] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff5f64fe3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff5f78e150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff5f55e8fe raise + 26 3 org.gnu.Emacs 0x00000001000a18da terminate_due_to_signal + 155 4 org.gnu.Emacs 0x00000001000b8fb6 emacs_abort + 19 5 org.gnu.Emacs 0x00000001001793fe ns_term_shutdown + 122 6 org.gnu.Emacs 0x00000001000a1ab4 shut_down_emacs + 262 7 org.gnu.Emacs 0x00000001000a18a5 terminate_due_to_signal + 102 8 org.gnu.Emacs 0x00000001000bb3a6 handle_fatal_signal + 14 9 org.gnu.Emacs 0x00000001000ba2dc deliver_fatal_thread_signal + 114 10 org.gnu.Emacs 0x00000001000bb44e handle_sigsegv + 168 11 libsystem_platform.dylib 0x00007fff5f781f5a _sigtramp + 26 12 ??? 000000000000000000 0 + 0 13 com.apple.AppKit 0x00007fff351c0d9d -[NSApplication run] + 812 14 org.gnu.Emacs 0x00000001001795b2 -[EmacsApp run] + 373 15 org.gnu.Emacs 0x000000010018434f ns_read_socket + 536 16 org.gnu.Emacs 0x00000001000ac523 gobble_input + 234 17 org.gnu.Emacs 0x00000001000ab3bb get_input_pending + 94 18 org.gnu.Emacs 0x00000001000a7769 read_char + 443 19 org.gnu.Emacs 0x00000001000a5ddf read_key_sequence + 1326 20 org.gnu.Emacs 0x00000001000a49c2 command_loop_1 + 783 21 org.gnu.Emacs 0x000000010010cf9b internal_condition_case + 82 22 org.gnu.Emacs 0x00000001000b0dc7 command_loop_2 + 37 23 org.gnu.Emacs 0x000000010010cb0b internal_catch + 73 24 org.gnu.Emacs 0x00000001000a3fc0 command_loop + 156 25 org.gnu.Emacs 0x00000001000a3ede recursive_edit_1 + 112 26 org.gnu.Emacs 0x00000001000a4100 Frecursive_edit + 228 27 org.gnu.Emacs 0x00000001000a2f63 main + 5206 28 libdyld.dylib 0x00007fff5f500115 start + 1 Thread 1:: gmain 0 libsystem_kernel.dylib 0x00007fff5f64ffca __select + 10 1 libglib-2.0.0.dylib 0x00000001009eeb60 g_poll + 430 2 libglib-2.0.0.dylib 0x00000001009e282f g_main_context_iterate + 340 3 libglib-2.0.0.dylib 0x00000001009e28dd g_main_context_iteration + 55 4 libglib-2.0.0.dylib 0x00000001009e398b glib_worker_main + 30 5 libglib-2.0.0.dylib 0x0000000100a03941 g_thread_proxy + 90 6 libsystem_pthread.dylib 0x00007fff5f78b6c1 _pthread_body + 340 7 libsystem_pthread.dylib 0x00007fff5f78b56d _pthread_start + 377 8 libsystem_pthread.dylib 0x00007fff5f78ac5d thread_start + 13 Thread 2: 0 libsystem_kernel.dylib 0x00007fff5f64ffca __select + 10 1 org.gnu.Emacs 0x000000010017a51a -[EmacsApp fd_handler:] + 219 2 com.apple.Foundation 0x00007fff39cc8ee8 __NSThread__start__ + 1197 3 libsystem_pthread.dylib 0x00007fff5f78b6c1 _pthread_body + 340 4 libsystem_pthread.dylib 0x00007fff5f78b56d _pthread_start + 377 5 libsystem_pthread.dylib 0x00007fff5f78ac5d thread_start + 13 Thread 3:: com.apple.NSEventThread 0 libsystem_kernel.dylib 0x00007fff5f6467c2 mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff5f645cdc mach_msg + 60 2 com.apple.CoreFoundation 0x00007fff37bea575 __CFRunLoopServiceMachPort + 341 3 com.apple.CoreFoundation 0x00007fff37be98c7 __CFRunLoopRun + 1783 4 com.apple.CoreFoundation 0x00007fff37be8f43 CFRunLoopRunSpecific + 483 5 com.apple.AppKit 0x00007fff353093c8 _NSEventThread + 184 6 libsystem_pthread.dylib 0x00007fff5f78b6c1 _pthread_body + 340 7 libsystem_pthread.dylib 0x00007fff5f78b56d _pthread_start + 377 8 libsystem_pthread.dylib 0x00007fff5f78ac5d thread_start + 13 Thread 4: 0 libsystem_pthread.dylib 0x00007fff5f78ac40 start_wqthread + 0 1 ??? 0x0000700005ec7b30 0 + 123145401695024 Thread 5:: Dispatch queue: NSCGSDisableUpdates 0 libsystem_kernel.dylib 0x00007fff5f6467c2 mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff5f645cdc mach_msg + 60 2 com.apple.SkyLight 0x00007fff59522285 CGSUpdateManager::enable_updates_common() + 565 3 com.apple.SkyLight 0x00007fff594c6b44 CGSUpdateManager::enable_update(unsigned long long) + 320 4 libdispatch.dylib 0x00007fff5f4ce591 _dispatch_call_block_and_release + 12 5 libdispatch.dylib 0x00007fff5f4c6d50 _dispatch_client_callout + 8 6 libdispatch.dylib 0x00007fff5f4db20c _dispatch_queue_serial_drain + 635 7 libdispatch.dylib 0x00007fff5f4ce0fd _dispatch_queue_invoke + 373 8 libdispatch.dylib 0x00007fff5f4dbf02 _dispatch_root_queue_drain_deferred_wlh + 332 9 libdispatch.dylib 0x00007fff5f4dfd16 _dispatch_workloop_worker_thread + 880 10 libsystem_pthread.dylib 0x00007fff5f78b033 _pthread_wqthread + 980 11 libsystem_pthread.dylib 0x00007fff5f78ac4d start_wqthread + 13 Thread 6: 0 libsystem_kernel.dylib 0x00007fff5f650562 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff5f78b26f _pthread_wqthread + 1552 2 libsystem_pthread.dylib 0x00007fff5f78ac4d start_wqthread + 13 Thread 7: 0 libsystem_kernel.dylib 0x00007fff5f650562 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff5f78b26f _pthread_wqthread + 1552 2 libsystem_pthread.dylib 0x00007fff5f78ac4d start_wqthread + 13 Thread 8: 0 libsystem_pthread.dylib 0x00007fff5f78ac40 start_wqthread + 0 1 ??? 0x0000000101642a00 0 + 4318308864 Thread 9: 0 libsystem_pthread.dylib 0x00007fff5f78ac40 start_wqthread + 0 1 ??? 0x0000000101643e00 0 + 4318313984 Thread 10: 0 libsystem_kernel.dylib 0x00007fff5f650562 __workq_kernreturn + 10 1 libsystem_pthread.dylib 0x00007fff5f78b26f _pthread_wqthread + 1552 2 libsystem_pthread.dylib 0x00007fff5f78ac4d start_wqthread + 13 Thread 11: 0 libsystem_pthread.dylib 0x00007fff5f78ac40 start_wqthread + 0 1 ??? 0x0000000101646600 0 + 4318324224 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x00007fff98556340 rcx: 0x00000001005c8198 rdx: 0x0000000000000000 rdi: 0x0000000000000307 rsi: 0x0000000000000006 rbp: 0x00000001005c81d0 rsp: 0x00000001005c8198 r8: 0x0000000000000015 r9: 0x00000001123ef410 r10: 0x0000000000000000 r11: 0x0000000000000287 r12: 0x0000000000000307 r13: 0x0000000101706150 r14: 0x0000000000000006 r15: 0x000000000000002d rip: 0x00007fff5f64fe3e rfl: 0x0000000000000286 cr2: 0x00007fe9a401a000 Logical CPU: 0 Error Code: 0x02000148 Trap Number: 133 ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-20 21:50 ` Aaron Jensen @ 2018-03-20 23:22 ` Aaron Jensen 2018-03-21 6:32 ` Eli Zaretskii 1 sibling, 0 replies; 43+ messages in thread From: Aaron Jensen @ 2018-03-20 23:22 UTC (permalink / raw) To: Alan Third; +Cc: 30699 On Tue, Mar 20, 2018 at 2:50 PM, Aaron Jensen <aaronjensen@gmail.com> wrote: > I've been having crashes on master today. Here's the dump (I didn't > have lldb attached at the time). Thread 5 is what pointed me to this: > This crash is still happening w/o this or the previous versions of the patch installed on the emacs-26 branch. I'm going to try running w/ lldb attached and see if I can't get some more info. If I do I'll open a new bug. Emacs has crashed at least 4 times today, so it's a bad one for me. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-20 21:50 ` Aaron Jensen 2018-03-20 23:22 ` Aaron Jensen @ 2018-03-21 6:32 ` Eli Zaretskii 2018-03-21 16:27 ` Aaron Jensen 1 sibling, 1 reply; 43+ messages in thread From: Eli Zaretskii @ 2018-03-21 6:32 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30699 > From: Aaron Jensen <aaronjensen@gmail.com> > Date: Tue, 20 Mar 2018 14:50:14 -0700 > Cc: Eli Zaretskii <eliz@gnu.org>, 30699@debbugs.gnu.org > > I've been having crashes on master today. Here's the dump (I didn't > have lldb attached at the time). Thread 5 is what pointed me to this: > > 3 com.apple.SkyLight 0x00007fff594c6b44 > CGSUpdateManager::enable_update(unsigned long long) + 320 That's an internal NS function, isn't it? AFAIU, the important part is this: > 10 org.gnu.Emacs 0x00000001000bb44e handle_sigsegv + 168 > 11 libsystem_platform.dylib 0x00007fff5f781f5a _sigtramp + 26 > 12 ??? 000000000000000000 0 + 0 > 13 com.apple.AppKit 0x00007fff351c0d9d > -[NSApplication run] + 812 > 14 org.gnu.Emacs 0x00000001001795b2 -[EmacsApp run] + 373 > 15 org.gnu.Emacs 0x000000010018434f ns_read_socket + 536 > 16 org.gnu.Emacs 0x00000001000ac523 gobble_input + 234 Why does [EmacsApp run] trigger a SIGSEGV? ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-21 6:32 ` Eli Zaretskii @ 2018-03-21 16:27 ` Aaron Jensen 0 siblings, 0 replies; 43+ messages in thread From: Aaron Jensen @ 2018-03-21 16:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, 30699 On Tue, Mar 20, 2018 at 11:32 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> CGSUpdateManager::enable_update(unsigned long long) + 320 > > That's an internal NS function, isn't it? Yeah, it was probably a red herring. > AFAIU, the important part is this: > >> 10 org.gnu.Emacs 0x00000001000bb44e handle_sigsegv + 168 >> 11 libsystem_platform.dylib 0x00007fff5f781f5a _sigtramp + 26 >> 12 ??? 000000000000000000 0 + 0 >> 13 com.apple.AppKit 0x00007fff351c0d9d >> -[NSApplication run] + 812 >> 14 org.gnu.Emacs 0x00000001001795b2 -[EmacsApp run] + 373 >> 15 org.gnu.Emacs 0x000000010018434f ns_read_socket + 536 >> 16 org.gnu.Emacs 0x00000001000ac523 gobble_input + 234 > > Why does [EmacsApp run] trigger a SIGSEGV? For posterity, as i know you've seen it, but see bug#30800 which is this crash. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-09 23:24 ` Alan Third 2018-03-10 0:25 ` Alan Third @ 2018-03-10 8:15 ` Eli Zaretskii 1 sibling, 0 replies; 43+ messages in thread From: Eli Zaretskii @ 2018-03-10 8:15 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Fri, 9 Mar 2018 23:24:15 +0000 > From: Alan Third <alan@idiocy.org> > Cc: 30699@debbugs.gnu.org, aaronjensen@gmail.com > > When the window manager resizes the frame it blanks its contents out. > This results in a flicker as the full redisplay only happens after the > user sees the blanked frame. Removing, or moving, SET_FRAME_GARBAGED > allows the frame contents to be redrawn before the user sees the blank > frame. > > What’s displayed is not correct but it’s shown for such a short time > that it’s not noticable, at least on my machine, and there is no > flicker. But without setting the frame's garbaged flag, the following redisplay might not produce an accurate display, and you will have that incorrect display longer than reasonable. The garbaged flag _must_ be set to force a complete redraw of the frame. If you can achieve the same effect by other means, or if you can show that the frame will be fully redrawn anyway, that could be a solution, but the frame _must_ be fully redrawn in this situation, after the glyph matrices of all of its windows are reallocated to reflect the new dimensions. So maybe a better solution would be to avoid blanking the frame when it's resized. Is that possible on NS? > It’s not a perfect solution, but it’s better than what we have at the > moment, IMO. Unless I'm misunderstanding, it's worse, actually. expose_frame is not prepared to deal with changed dimensions, it assumes that all the dimensions are as last recorded, and that the glyph matrices accurately describe what should be shown on the glass. Calling expose_frame when these assumptions are blatantly false is asking for trouble. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-04 21:34 ` Alan Third 2018-03-05 2:06 ` Aaron Jensen @ 2018-03-05 7:55 ` Aaron Jensen 2018-03-05 16:12 ` Eli Zaretskii 2018-03-06 23:00 ` Alan Third 1 sibling, 2 replies; 43+ messages in thread From: Aaron Jensen @ 2018-03-05 7:55 UTC (permalink / raw) To: Alan Third; +Cc: 30699 On Sun, Mar 4, 2018 at 1:34 PM, Alan Third <alan@idiocy.org> wrote: > The root problem is actually that we’re unable to execute redisplay > while the frame is being resized by a mouse. The NS event loop goes > into some ‘modal’ state which we can’t break out of, thus preventing > us from doing anything until it’s done. If that didn’t happen we > wouldn’t need to blank the screen at all. Is this true on a mac as well? How are other apps like iTerm2 able to redraw during a resize? It's a naive question, but is it at all possible to redraw a garbaged frame w/o a flicker? I know nothing about the drawing code, so I apologize for the question if it's dumb. Thanks, Aaron ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 7:55 ` Aaron Jensen @ 2018-03-05 16:12 ` Eli Zaretskii 2018-03-06 23:00 ` Alan Third 1 sibling, 0 replies; 43+ messages in thread From: Eli Zaretskii @ 2018-03-05 16:12 UTC (permalink / raw) To: Aaron Jensen; +Cc: alan, 30699 > From: Aaron Jensen <aaronjensen@gmail.com> > Date: Sun, 4 Mar 2018 23:55:50 -0800 > Cc: 30699@debbugs.gnu.org > > It's a naive question, but is it at all possible to redraw a garbaged > frame w/o a flicker? AFAIK, no. Redrawing a garbaged frame involves clearing it and completely redrawing all of its windows, and that is what you perceive as flicker. ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-05 7:55 ` Aaron Jensen 2018-03-05 16:12 ` Eli Zaretskii @ 2018-03-06 23:00 ` Alan Third 2018-03-07 17:26 ` Eli Zaretskii 1 sibling, 1 reply; 43+ messages in thread From: Alan Third @ 2018-03-06 23:00 UTC (permalink / raw) To: Aaron Jensen; +Cc: 30699 On Sun, Mar 04, 2018 at 11:55:50PM -0800, Aaron Jensen wrote: > On Sun, Mar 4, 2018 at 1:34 PM, Alan Third <alan@idiocy.org> wrote: > > The root problem is actually that we’re unable to execute redisplay > > while the frame is being resized by a mouse. The NS event loop goes > > into some ‘modal’ state which we can’t break out of, thus preventing > > us from doing anything until it’s done. If that didn’t happen we > > wouldn’t need to blank the screen at all. > > Is this true on a mac as well? How are other apps like iTerm2 able to > redraw during a resize? The short answer is that iTerm2 is a native Cocoa app, written in the way you should write Cocoa apps. Emacs isn’t. The long answer is quite complicated. I’m trying to write up a decent explanation of how the NS port works. > It's a naive question, but is it at all possible to redraw a garbaged > frame w/o a flicker? I know nothing about the drawing code, so I > apologize for the question if it's dumb. It should be, but I know very little about how Emacs goes about drawing the frame contents, so I won’t say definitely. -- Alan Third ^ permalink raw reply [flat|nested] 43+ messages in thread
* bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized 2018-03-06 23:00 ` Alan Third @ 2018-03-07 17:26 ` Eli Zaretskii 0 siblings, 0 replies; 43+ messages in thread From: Eli Zaretskii @ 2018-03-07 17:26 UTC (permalink / raw) To: Alan Third; +Cc: 30699, aaronjensen > Date: Tue, 6 Mar 2018 23:00:40 +0000 > From: Alan Third <alan@idiocy.org> > Cc: 30699@debbugs.gnu.org > > I know very little about how Emacs goes about drawing the frame > contents Feel free to ask me questions. ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2018-03-21 16:27 UTC | newest] Thread overview: 43+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-04 17:38 bug#30699: 26.0.91; buffer contents flicker on macOS frames when frames are resized Aaron Jensen 2018-03-04 20:27 ` Alan Third 2018-03-04 21:34 ` Alan Third 2018-03-05 2:06 ` Aaron Jensen 2018-03-05 3:27 ` Eli Zaretskii 2018-03-05 5:21 ` Aaron Jensen 2018-03-05 16:01 ` Eli Zaretskii 2018-03-05 16:21 ` Aaron Jensen 2018-03-05 18:00 ` Eli Zaretskii 2018-03-05 19:23 ` Alan Third 2018-03-05 19:53 ` Eli Zaretskii 2018-03-06 22:55 ` Alan Third 2018-03-07 17:26 ` Eli Zaretskii 2018-03-07 20:26 ` Alan Third 2018-03-08 19:15 ` Eli Zaretskii 2018-03-09 12:09 ` Alan Third 2018-03-09 13:32 ` Eli Zaretskii 2018-03-09 23:24 ` Alan Third 2018-03-10 0:25 ` Alan Third 2018-03-10 1:18 ` Aaron Jensen 2018-03-10 8:30 ` Eli Zaretskii 2018-03-10 23:07 ` Alan Third 2018-03-11 16:29 ` Eli Zaretskii 2018-03-12 0:46 ` Alan Third 2018-03-12 16:39 ` Eli Zaretskii 2018-03-12 23:42 ` Alan Third 2018-03-13 12:19 ` Alan Third 2018-03-13 16:56 ` Eli Zaretskii 2018-03-13 20:18 ` Alan Third 2018-03-13 15:34 ` Aaron Jensen 2018-03-14 15:08 ` Alan Third 2018-03-19 15:15 ` Alan Third 2018-03-19 15:27 ` Eli Zaretskii 2018-03-19 17:19 ` Alan Third 2018-03-20 21:50 ` Aaron Jensen 2018-03-20 23:22 ` Aaron Jensen 2018-03-21 6:32 ` Eli Zaretskii 2018-03-21 16:27 ` Aaron Jensen 2018-03-10 8:15 ` Eli Zaretskii 2018-03-05 7:55 ` Aaron Jensen 2018-03-05 16:12 ` Eli Zaretskii 2018-03-06 23:00 ` Alan Third 2018-03-07 17:26 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).