unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* 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-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  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  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 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-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 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-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

* 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-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-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-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 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-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

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).