bug#32932: 27.0.50; render bugs on macOS Mojave

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

I apologize if this is tracked elsewhere. The current master build with
the new drawRect rendering seems to occasionally paint a blank buffer.
As I move the point, the line the point is on fills in. I don't know how
to reproduce this consistently, it just happens with normal use.


In GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin18.0.0, NS appkit-1671.00 Version 10.14 (Build 18A391))
 of 2018-10-03 built on aaron-mbt.local
Repository revision: 945a7622326f7d93dd318f01d54f6bf23e0021cf
Windowing system distributor 'Apple', version 10.3.1671
System Description:  Mac OS X 10.14

Recent messages:
Added 4 events for today
Saving file /Users/aaronjensen/.emacs.d/.cache/work.org...
Wrote /Users/aaronjensen/.emacs.d/.cache/work.org
Saving file /Users/aaronjensen/.emacs.d/.cache/personal.org...
Wrote /Users/aaronjensen/.emacs.d/.cache/personal.org
Showing all blocks ... done
Showing all blocks ... done
Added 4 events for today
evil-line-move: End of buffer
Mark set
evil-line-move: End of buffer
Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs-plus/HEAD-945a762/share/info/emacs
 --prefix=/usr/local/Cellar/emacs-plus/HEAD-945a762 --with-xml2
 --without-dbus --with-gnutls --with-imagemagick --with-modules
 --with-rsvg --with-ns --disable-ns-self-contained'

Configured features:
RSVG IMAGEMAGICK GLIB NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS
NS MODULES THREADS LCMS2 GMP

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: typescript

Minor modes in effect:
  prettier-js-mode: t
  tide-mode: t
  eros-mode: t
  eval-sexp-fu-flash-mode: t
  magit-todos-mode: t
  global-magit-file-mode: t
  magit-file-mode: t
  magit-auto-revert-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  diff-auto-refine-mode: t
  eslintd-fix-mode: t
  company-statistics-mode: t
  company-posframe-mode: t
  goto-address-prog-mode: t
  bug-reference-prog-mode: t
  auto-highlight-symbol-mode: t
  dtrt-indent-mode: t
  flycheck-posframe-mode: t
  flycheck-pos-tip-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  highlight-numbers-mode: t
  highlight-parentheses-mode: t
  rainbow-delimiters-mode: t
  show-smartparens-global-mode: t
  show-smartparens-mode: t
  smartparens-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  pupo-mode: t
  purpose-mode: t
  evil-escape-mode: t
  global-git-gutter+-mode: t
  git-gutter+-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  recentf-mode: t
  desktop-save-mode: t
  ivy-prescient-mode: t
  company-prescient-mode: t
  prescient-persist-mode: t
  company-mode: t
  global-wakatime-mode: t
  wakatime-mode: t
  evil-mc-mode: t
  hl-todo-mode: t
  eldoc-in-minibuffer-mode: t
  winner-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
  global-vi-tilde-fringe-mode: t
  vi-tilde-fringe-mode: t
  save-place-mode: t
  savehist-mode: t
  projectile-rails-global-mode: t
  projectile-mode: t
  persp-mode: t
  global-origami-mode: t
  origami-mode: t
  eyebrowse-mode: t
  global-anzu-mode: t
  anzu-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
  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/27.0/develop/ht-20180129.2234/ht hides /Users/aaronjensen/.emacs.d/core/libs/ht
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/inf-ruby-20180521.1348/inf-ruby hides /usr/local/share/emacs/site-lisp/ruby/inf-ruby
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-stan hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-stan
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-exp hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-exp
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-J hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-J
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-eshell hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-eshell
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-emacs-lisp hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-emacs-lisp
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-gnus hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-gnus
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-css hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-css
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-lob hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-lob
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-forth hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-forth
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-macs hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-macs
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-version hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-version
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-scheme hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-scheme
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-abc hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-abc
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-C hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-C
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-capture hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-capture
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-ref hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-ref
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-clojure hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-clojure
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-mouse hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-mouse
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-ledger hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-ledger
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-ctags hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-ctags
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-entities hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-entities
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-archive hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-archive
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-screen hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-screen
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-haskell hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-haskell
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-asymptote hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-asymptote
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-mhe hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-mhe
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-table hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-table
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-keys hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-keys
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-org hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-org
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-plot hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-plot
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-awk hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-awk
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-groovy hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-groovy
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-octave hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-octave
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-faces hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-faces
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-colview hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-colview
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-R hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-R
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-timer hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-timer
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-ebnf hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-ebnf
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-mobile hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-mobile
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-fortran hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-fortran
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-shell hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-shell
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-perl hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-perl
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-sqlite hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-sqlite
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-sed hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-sed
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-list hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-list
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-ruby hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-ruby
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-eval hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-eval
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-habit hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-habit
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-clock hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-clock
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-html hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-html
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-src hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-src
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-lisp hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-lisp
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-ditaa hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-ditaa
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-pcomplete hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-pcomplete
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-lint hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-lint
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-rmail hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-rmail
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-latex hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-latex
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-sass hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-sass
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-io hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-io
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-tangle hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-tangle
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-calc hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-calc
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-java hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-java
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-icalendar hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-icalendar
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-eww hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-eww
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-md hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-md
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-beamer hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-beamer
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-element hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-element
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-protocol hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-protocol
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-mscgen hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-mscgen
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-gnuplot hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-gnuplot
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-latex hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-latex
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-id hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-id
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-vala hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-vala
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-man hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-man
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-feed hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-feed
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-lua hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-lua
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-table hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-table
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-ocaml hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-ocaml
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-coq hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-coq
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-picolisp hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-picolisp
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-indent hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-indent
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-lilypond hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-lilypond
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-matlab hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-matlab
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-datetree hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-datetree
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-python hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-python
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-bbdb hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-bbdb
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-makefile hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-makefile
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-duration hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-duration
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-agenda hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-agenda
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-dot hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-dot
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-js hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-js
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-publish hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-publish
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-inlinetask hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-inlinetask
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-org hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-org
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-core hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-core
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-compat hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-compat
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-docview hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-docview
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-odt hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-odt
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-plantuml hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-plantuml
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-ascii hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-ascii
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-loaddefs hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-loaddefs
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-w3m hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-w3m
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-bibtex hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-bibtex
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-info hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-info
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-hledger hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-hledger
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-maxima hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-maxima
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-macro hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-macro
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-sql hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-sql
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-attach hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-attach
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-processing hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-processing
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ox-texinfo hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ox-texinfo
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-irc hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-irc
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-crypt hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-crypt
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-footnote hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-footnote
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/org-install hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/org-install
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-comint hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-comint
/Users/aaronjensen/.emacs.d/elpa/27.0/develop/org-plus-contrib-20180924/ob-shen hides /usr/local/Cellar/emacs-plus/HEAD-945a762/share/emacs/27.0.50/lisp/org/ob-shen

Features:
(shadow sort mail-extr emacsbug sendmail smex prettier-js tide tide-lv
company-oddmuse company-etags company-gtags company-cmake company-xcode
company-clang company-semantic company-eclim company-template
company-bbdb typescript-mode misearch multi-isearch appt diary-lib
diary-loaddefs org-duration company-robe robe rubocop ruby-refactor
ruby-tools evil-matchit evil-matchit-sdk overseer auto-compile packed
elisp-slime-nav eros flycheck-package package-lint finder lispyville
lispy lispy-inline avy edebug backtrace lispy-tags mode-local nameless
eval-sexp-fu highlight font-lock+ frame-fns avoid json-mode
json-reformat json-snatcher company-lua smartparens-lua lua-mode
alchemist alchemist-macroexpand alchemist-company alchemist-help
alchemist-complete alchemist-refcard alchemist-phoenix alchemist-compile
alchemist-iex alchemist-message alchemist-hooks alchemist-hex
alchemist-mix alchemist-info alchemist-goto alchemist-scope
alchemist-eval alchemist-interact alchemist-server alchemist-execute
alchemist-report alchemist-test-mode alchemist-project alchemist-file
alchemist-key alchemist-utils flycheck-dialyxir smartparens-elixir
elixir-mode elixir-format pkg-info epl elixir-smie sh-script org-agenda
view company-emoji company-emoji-list org-eldoc evil-org org-table ob-C
ob-shell ob-js ob-ruby org-bullets org-download toc-org typo
org-variable-pitch 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 org-gcal org-archive request-deferred deferred request
alert log4e notifications dbus xml gntp face-remap gravatar url-cache
magithub-completion fill-column-indicator magit-todos smartparens-org
ob-async ob-elixir ob-http ob-http-mode ob-restclient restclient 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 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 magit-gitflow
magithub magithub-dash magithub-notification magithub-orgs
magithub-issue-tricks magithub-issue-post magithub-edit-mode
magithub-repo magithub-ci magithub-issue magithub-label magithub-user
magithub-core magithub-faces magithub-settings smartparens-markdown
markdown-mode 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 gh-profile 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-graphql treepy graphql ghub
url-http url-gw url-auth url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf mailcap magit-files
magit-refs magit-status magit magit-repos magit-apply magit-wip
magit-log which-func magit-diff smerge-mode magit-core magit-autorevert
magit-process magit-margin magit-mode executable network-stream nsm
company-tng evil-surround vc-git diff-mode eslintd-fix flow-minor-mode
flycheck-flow company-statistics company-posframe company-files
company-keywords company-capf company-dabbrev-code company-dabbrev
company-flow js-doc iswitchb js2-refactor js2r-paredit js2r-conveniences
js2r-conditionals js2r-wrapping js2r-functions js2r-vars
multiple-cursors-core js2r-iife js2r-formatting js2r-helpers skewer-mode
cache-table simple-httpd pp url-util add-node-modules-path
js2-imenu-extras goto-addr bug-reference auto-highlight-symbol
dtrt-indent evil-lisp-state flycheck-credo flycheck-posframe posframe
flycheck-pos-tip pos-tip flycheck find-func highlight-numbers
parent-mode highlight-parentheses hideshow rainbow-delimiters
smartparens-config smartparens-javascript smartparens-text
smartparens-ruby smartparens-html smartparens yasnippet-snippets
yasnippet elec-pair cursor-sensor rjsx-mode js2-mode etags multifile
generator js sgml-mode dom cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs editorconfig-core
editorconfig-core-handle editorconfig-fnmatch spacemacs-purpose-popwin
window-purpose-x imenu-list imenu window-purpose window-purpose-fixes
window-purpose-prefix-overload window-purpose-switch
window-purpose-layout window-purpose-core window-purpose-configuration
window-purpose-utils evil-escape counsel-projectile 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 recentf tree-widget
desktop frameset ivy-prescient company-prescient prescient company
wakatime-mode contextual-menubar evil-collection-integration
evil-collection-dired evil-collection-custom evil-collection
init-doom-modeline powerline-separators quiet-emacs fill-or-unfill
init-macos-terminal-copy-paste 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 doom-modeline shrink-path
eldoc-eval all-the-icons all-the-icons-faces data-material
data-weathericons data-octicons data-fileicons data-faicons
data-alltheicons memoize persistent-soft list-utils pcache eieio-base
font-utils server winner xterm-color spacemacs-whitespace-cleanup
ws-butler winum vi-tilde-fringe unicode-fonts tmux string-inflection
saveplace savehist ruby-test-mode pcre2el rxt re-builder
projectile-rails rake f inflections inf-ruby ruby-mode smie projectile
grep ibuf-ext ibuffer ibuffer-loaddefs popwin persp-mode osx-trash
origami origami-parsers s ivy-hydra google-c-style eyebrowse dash
evil-anzu anzu editorconfig noutline outline counsel xref project dired
dired-loaddefs compile swiper ivy flx delsel colir color ivy-overlay
ffap clean-aindent-mode gh-common marshal fix-word docker-tramp
tramp-cache hybrid-mode 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 mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr lisp-mnt help-fns
radix-tree hl-line xt-mouse autorevert filenotify disp-table wid-edit
night-owl-theme info finder-inf patch-server init-sass init-php
init-html init-evil tramp trampver tramp-compat tramp-loaddefs 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-progress-bar core-spacemacs-buffer core-funcs ht cl
warnings package let-alist cl-extra help-mode url-handlers url-parse
auth-source cl-seq password-cache json map 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
profiler easymenu core-hooks page-break-lines easy-mmode core-env
load-env-vars rx cl-loaddefs cl-lib core-dotspacemacs advice
core-emacs-backports subr-x core-dumper 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 threads kqueue cocoa ns lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 2510144 368878)
 (symbols 48 93241 32)
 (strings 32 677890 134620)
 (string-bytes 1 29160719)
 (vectors 16 152632)
 (vector-slots 8 3063822 398646)
 (floats 8 1621 2470)
 (intervals 56 39946 5789)
 (buffers 992 224))

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Thu, 4 Oct 2018, 14:07 Aaron Jensen, <aaronjensen@gmail.com> wrote:

>
> I apologize if this is tracked elsewhere. The current master build with
> the new drawRect rendering seems to occasionally paint a blank buffer.
> As I move the point, the line the point is on fills in. I don't know how
> to reproduce this consistently, it just happens with normal use.
>

Hi Aaron,

Does it only blank the whole frame, or does it do it to certain areas?

Can you send the output from compiling the .m files?

Thanks.

>

[-- Attachment #2: Type: text/html, Size: 1146 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Charles A. Roelli]

> From: Alan Third <athird@googlemail.com>
> Date: Thu, 4 Oct 2018 15:07:13 +0100
> 
> On Thu, 4 Oct 2018, 14:07 Aaron Jensen, <aaronjensen@gmail.com> wrote:
> 
>  I apologize if this is tracked elsewhere. The current master build with
>  the new drawRect rendering seems to occasionally paint a blank buffer.
>  As I move the point, the line the point is on fills in. I don't know how
>  to reproduce this consistently, it just happens with normal use.
> 
> Hi Aaron,
> 
> Does it only blank the whole frame, or does it do it to certain areas?
> 
> Can you send the output from compiling the .m files? 
> 
> Thanks.

FWIW, I saw the same thing on macOS 10.6 on a recent build of master
(with the new rendering approach), but was unable to produce the issue
again.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On October 4, 2018 at 7:07:25 AM, Alan Third
(athird@googlemail.com(mailto:athird@googlemail.com)) wrote:

> Does it only blank the whole frame, or does it do it to certain areas?

I typically see the whole frame. Sometimes the “wrong” image is
displayed as well, it’ll be off by one line or so, so as I move the
point around the correct line fills in and I’ll see duplicate lines. I
don’t know if that makes sense, but it’s as if the image was scrolled
up one line but the buffer wasn’t actually and when it redraws the
line the point is on it draws the correct line.

> Can you send the output from compiling the .m files?

The .o files? Attached, hopefully that’s what you wanted, but if not
just let me know how to get what you want.

Aaron

[-- Attachment #2: out.tar.gz --]
[-- Type: application/octet-stream, Size: 144902 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Thu, Oct 04, 2018 at 10:48:59AM -0700, Aaron Jensen wrote:
> On October 4, 2018 at 7:07:25 AM, Alan Third
> (athird@googlemail.com(mailto:athird@googlemail.com)) wrote:
> 
> > Does it only blank the whole frame, or does it do it to certain areas?
> 
> I typically see the whole frame. Sometimes the “wrong” image is
> displayed as well, it’ll be off by one line or so, so as I move the
> point around the correct line fills in and I’ll see duplicate lines. I
> don’t know if that makes sense, but it’s as if the image was scrolled
> up one line but the buffer wasn’t actually and when it redraws the
> line the point is on it draws the correct line.

Is it possible that ‘one line’ is the same as the height of the title
bar?

> > Can you send the output from compiling the .m files?
> 
> The .o files? Attached, hopefully that’s what you wanted, but if not
> just let me know how to get what you want.

Sorry, I was unclear. I meant the compiler warnings etc. But since
Charles sees this on 10.6 it’s unlikely it’s something new in the
compilation.

All I can think of to do is enable NSTRACE and see if you can spot
some commonality when the problem happens.

-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

You lost the bug tracker again.

On Thu, Oct 04, 2018 at 11:34:41AM -0700, Aaron Jensen wrote:
> On October 4, 2018 at 11:25:19 AM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> 
> > Is it possible that ‘one line’ is the same as the height of the title
> > bar?
> 
> That’s possible, yes.
> 
> > Sorry, I was unclear. I meant the compiler warnings etc. But since
> > Charles sees this on 10.6 it’s unlikely it’s something new in the
> > compilation.
> >
> > All I can think of to do is enable NSTRACE and see if you can spot
> > some commonality when the problem happens.
> 
> Any particular groups you want me to include in the trace?

No. It’s possible that updates and focus could give some extra clue,
but they also might just end up littering the output with nonsense.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

> Is it possible that ‘one line’ is the same as the height of the title
> bar?

That’s possible, yes.

> Sorry, I was unclear. I meant the compiler warnings etc. But since
> Charles sees this on 10.6 it’s unlikely it’s something new in the
> compilation.
>
> All I can think of to do is enable NSTRACE and see if you can spot
> some commonality when the problem happens.

Any particular groups you want me to include in the trace?

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

On Thu, Oct 04, 2018 at 07:45:49PM +0100, Alan Third wrote:
> You lost the bug tracker again.
> 
> On Thu, Oct 04, 2018 at 11:34:41AM -0700, Aaron Jensen wrote:
> > On October 4, 2018 at 11:25:19 AM, Alan Third
> > (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> > 
> > > Is it possible that ‘one line’ is the same as the height of the title
> > > bar?
> > 
> > That’s possible, yes.
> > 
> > > Sorry, I was unclear. I meant the compiler warnings etc. But since
> > > Charles sees this on 10.6 it’s unlikely it’s something new in the
> > > compilation.
> > >
> > > All I can think of to do is enable NSTRACE and see if you can spot
> > > some commonality when the problem happens.
> > 
> > Any particular groups you want me to include in the trace?
> 
> No. It’s possible that updates and focus could give some extra clue,
> but they also might just end up littering the output with nonsense.

Can you try the attached patch? I noticed that nested calls to
ns_clip_to_row would probably fail to reset the graphics context
correctly (and therefore the clipping areas for drawing). I’ve no idea
if that’s actually a problem for us, though.
-- 
Alan Third

[-- Attachment #2: 0001-Fix-occasional-redraw-error-bug-32932.patch --]
[-- Type: text/plain, Size: 1313 bytes --]

From e81bf671f31663359e2572e8c183f3a4d7e5f708 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Thu, 4 Oct 2018 22:47:23 +0100
Subject: [PATCH] Fix occasional redraw error (bug#32932)

* src/nsterm.m (ns_clip_to_rect, ns_reset_clipping): Always pop the
graphics state.
---
 src/nsterm.m | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index d92d6c3244..72ad57c64d 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -277,7 +277,6 @@ - (NSColor *)colorUsingDefaultColorSpace
 
 /* display update */
 static int ns_window_num = 0;
-static BOOL gsaved = NO;
 static BOOL ns_fake_keydown = NO;
 #ifdef NS_IMPL_COCOA
 static BOOL ns_menu_bar_is_hidden = NO;
@@ -1180,7 +1179,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
             NSRectClipList (r, 2);
           else
             NSRectClip (*r);
-          gsaved = YES;
 
           return YES;
         }
@@ -1204,11 +1202,7 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 {
   NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "ns_reset_clipping");
 
-  if (gsaved)
-    {
-      [[NSGraphicsContext currentContext] restoreGraphicsState];
-      gsaved = NO;
-    }
+  [[NSGraphicsContext currentContext] restoreGraphicsState];
 }
 
 
-- 
2.18.0

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 4, 2018 at 2:51:58 PM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

No dice. I have a consistent repro if you’d like to screen share, I’d
be happy to.

Here’s some logging:

nsterm.m  : 5910: [ 7729]  [EmacsApp applicationWillBecomeActive:]
nsterm.m  : 7218: [ 7730]  [EmacsView windowDidBecomeKey]
nsterm.m  : 1546: [ 7731]  | ns_frame_rehighlight
nsterm.m  : 3159: [ 7732]  | | ns_draw_window_cursor
nsterm.m  : 3159: [ 7733]  | | ns_draw_window_cursor
nsterm.m  : 2436: [ 7734]  | | x_set_frame_alpha
nsterm.m  : 5916: [ 7735]  [EmacsApp applicationDidBecomeActive:]
nsterm.m  : 1048: [ 7736]  | ns_update_auto_hide_menu_bar
nsterm.m  : 1017: [ 7737]  | ns_constrain_all_frames
nsterm.m  : 7835: [ 7738]  | | [EmacsView isFullscreen] ->> 0
nsterm.m  :  904: [ 7739]  | | constrain_frame_rect((X:24 Y:292)/(W:674 H:96))
nsterm.m  :  927: [ 7740]  | | +--- Screen 0: (X:0 Y:0)/(W:2560 H:1440)
nsterm.m  :  746: [ 7741]  | | | ns_screen_margins
nsterm.m  :  782: [ 7742]  | | | +--- left:0 right:0 top:23 bottom:0
nsterm.m  :  847: [ 7743]  | | | ns_menu_bar_height ->> 23
nsterm.m  :  927: [ 7744]  | | +--- Screen 1: (X:-1440 Y:540)/(W:1440 H:900)
nsterm.m  :  941: [ 7745]  | | +--- multiscreenRect: (X:0 Y:0)/(W:2560 H:1440)
nsterm.m  :  943: [ 7746]  | | +--- menu_bar_height: 23
nsterm.m  : 1004: [ 7747]  | | +->> (X:24 Y:292)/(W:674 H:96)
nsterm.m  : 8654: [ 7748]  | | [EmacsWindow setFrame:(X:24
Y:292)/(W:674 H:96) display:0]
nsterm.m  : 7835: [ 7749]  | | [EmacsView isFullscreen] ->> 0
nsterm.m  :  904: [ 7750]  | | constrain_frame_rect((X:232 Y:369)/(W:96 H:19))
nsterm.m  :  927: [ 7751]  | | +--- Screen 0: (X:0 Y:0)/(W:2560 H:1440)
nsterm.m  :  746: [ 7752]  | | | ns_screen_margins
nsterm.m  :  782: [ 7753]  | | | +--- left:0 right:0 top:23 bottom:0
nsterm.m  :  847: [ 7754]  | | | ns_menu_bar_height ->> 23
nsterm.m  :  927: [ 7755]  | | +--- Screen 1: (X:-1440 Y:540)/(W:1440 H:900)
nsterm.m  :  941: [ 7756]  | | +--- multiscreenRect: (X:0 Y:0)/(W:2560 H:1440)
nsterm.m  :  943: [ 7757]  | | +--- menu_bar_height: 23
nsterm.m  : 1004: [ 7758]  | | +->> (X:232 Y:369)/(W:96 H:19)
nsterm.m  : 8654: [ 7759]  | | [EmacsWindow setFrame:(X:232
Y:369)/(W:96 H:19) display:0]
nsterm.m  : 7835: [ 7760]  | | [EmacsView isFullscreen] ->> 0
nsterm.m  :  904: [ 7761]  | | constrain_frame_rect((X:0 Y:0)/(W:1484 H:1417))
nsterm.m  :  927: [ 7762]  | | +--- Screen 0: (X:0 Y:0)/(W:2560 H:1440)
nsterm.m  :  746: [ 7763]  | | | ns_screen_margins
nsterm.m  :  782: [ 7764]  | | | +--- left:0 right:0 top:23 bottom:0
nsterm.m  :  847: [ 7765]  | | | ns_menu_bar_height ->> 23
nsterm.m  :  927: [ 7766]  | | +--- Screen 1: (X:-1440 Y:540)/(W:1440 H:900)
nsterm.m  :  941: [ 7767]  | | +--- multiscreenRect: (X:0 Y:0)/(W:2560 H:1440)
nsterm.m  :  943: [ 7768]  | | +--- menu_bar_height: 23
nsterm.m  : 1004: [ 7769]  | | +->> (X:0 Y:0)/(W:1484 H:1417)
nsterm.m  : 8654: [ 7770]  | | [EmacsWindow setFrame:(X:0 Y:0)/(W:1484
H:1417) display:0]
nsterm.m  : 6199: [ 7771]  [EmacsView keyDown:]
nsterm.m  : 6490: [ 7772]  | [EmacsView hasMarkedText]
nsterm.m  : 6383: [ 7773]  | [EmacsView insertText:]
nsterm.m  : 6199: [ 7774]  [EmacsView keyDown:]
nsterm.m  : 6490: [ 7775]  | [EmacsView hasMarkedText]
nsterm.m  : 6383: [ 7776]  | [EmacsView insertText:]
nsterm.m  : 7238: [ 7777]  [EmacsView windowDidResignKey:]
nsterm.m  : 1546: [ 7778]  | ns_frame_rehighlight
nsterm.m  : 3159: [ 7779]  | ns_draw_window_cursor
nsterm.m  : 3159: [ 7780]  | ns_draw_window_cursor
nsterm.m  : 2436: [ 7781]  | x_set_frame_alpha
nsterm.m  : 6469: [ 7782]  | [EmacsView deleteWorkingText]
nsterm.m  : 5930: [ 7783]  [EmacsApp applicationDidResignActive:]

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Boris Buliga]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

I have the same issue.

Usually, it happens during resizing. But I've seen it several times without
resizing.

The same, let me know if you need any help to track it down.

On Tue, 9 Oct 2018 at 09:38, Aaron Jensen <aaronjensen@gmail.com> wrote:

> On October 4, 2018 at 4:03:14 PM, Aaron Jensen
> (aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:
>
> > On October 4, 2018 at 2:51:58 PM, Alan Third (alan@idiocy.org(mailto:
> alan@idiocy.org)) wrote:
> >
> > No dice. I have a consistent repro if you’d like to screen share, I’d be
> happy to.
>
> I have another way to reproduce it—by resizing the frame. Occasionally
> it’ll fail to paint the entire frame. It appears that I can only
> reproduce it while the point is on something that triggers an eldoc
> tip in the minibuffer.
>
> I wasn’t able to record a gif of it (any screenshot or gif I record
> acts as if it painted successfully) but the video I attached shows the
> behavior. I can’t say for certain that this is the same thing I see in
> normal usage when I’m not resizing things, but it certainly looks to
> be the same type of artifact. Sometimes it’s a previous painting
> that’s left around and sometimes it’s a blank. I’m sure it’s a blank
> in this case because it blanks while resizing.
>
> Hopefully that helps track it down. Let me know if there’s anything
> you’d like me to try.
>
> Thanks,
>
> Aaron
>


-- 
Cheers,
Boris

[-- Attachment #2: Type: text/html, Size: 2213 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Tue, Oct 09, 2018 at 10:15:18AM +0300, Boris Buliga wrote:
> Usually, it happens during resizing. But I've seen it several times without
> resizing.

I doubt this will make any difference, but can one of you try removing
the called to [window display] in windowWillResize in nsterm.m

-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 10, 2018 at 11:27:54 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> On Tue, Oct 09, 2018 at 10:15:18AM +0300, Boris Buliga wrote:
> > Usually, it happens during resizing. But I've seen it several times without
> > resizing.
>
> I doubt this will make any difference, but can one of you try removing
> the called to [window display] in windowWillResize in nsterm.m

I can still repro with this change made. Also, it’s not just on
resizing, it happens often just while using it w/ a fixed window size.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 10, 2018 at 8:40:18 PM, Aaron Jensen
(aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:

> On October 10, 2018 at 11:27:54 AM, Alan Third (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
>
> > On Tue, Oct 09, 2018 at 10:15:18AM +0300, Boris Buliga wrote:
> > > Usually, it happens during resizing. But I've seen it several times without
> > > resizing.
> >
> > I doubt this will make any difference, but can one of you try removing
> > the called to [window display] in windowWillResize in nsterm.m
>
> I can still repro with this change made. Also, it’s not just on resizing, it happens often just while using it w/ a fixed window size.

On a whim, I commented out:

  [FRAME_NS_VIEW (f) displayIfNeeded];

In ns_flush_display. I cannot reproduce the problem with that
commented out. I don’t know what ill effects it will have, but so far
it seems like things draw properly.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Boris Buliga]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

Thank you for suggestion. I will try it out as well.

On Sun, Oct 14, 2018 at 11:19 Aaron Jensen <aaronjensen@gmail.com> wrote:

> On October 10, 2018 at 8:40:18 PM, Aaron Jensen
> (aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:
>
> > On October 10, 2018 at 11:27:54 AM, Alan Third (alan@idiocy.org(mailto:
> alan@idiocy.org)) wrote:
> >
> > > On Tue, Oct 09, 2018 at 10:15:18AM +0300, Boris Buliga wrote:
> > > > Usually, it happens during resizing. But I've seen it several times
> without
> > > > resizing.
> > >
> > > I doubt this will make any difference, but can one of you try removing
> > > the called to [window display] in windowWillResize in nsterm.m
> >
> > I can still repro with this change made. Also, it’s not just on
> resizing, it happens often just while using it w/ a fixed window size.
>
> On a whim, I commented out:
>
>   [FRAME_NS_VIEW (f) displayIfNeeded];
>
> In ns_flush_display. I cannot reproduce the problem with that
> commented out. I don’t know what ill effects it will have, but so far
> it seems like things draw properly.
>
> Aaron
>
-- 
Cheers,
Boris

[-- Attachment #2: Type: text/html, Size: 1864 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

On Sun, Oct 14, 2018 at 01:19:50AM -0700, Aaron Jensen wrote:
> On October 10, 2018 at 8:40:18 PM, Aaron Jensen
> (aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:
> 
> > On October 10, 2018 at 11:27:54 AM, Alan Third (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> >
> > > On Tue, Oct 09, 2018 at 10:15:18AM +0300, Boris Buliga wrote:
> > > > Usually, it happens during resizing. But I've seen it several times without
> > > > resizing.
> > >
> > > I doubt this will make any difference, but can one of you try removing
> > > the called to [window display] in windowWillResize in nsterm.m
> >
> > I can still repro with this change made. Also, it’s not just on resizing, it happens often just while using it w/ a fixed window size.
> 
> On a whim, I commented out:
> 
>   [FRAME_NS_VIEW (f) displayIfNeeded];
> 
> In ns_flush_display. I cannot reproduce the problem with that
> commented out. I don’t know what ill effects it will have, but so far
> it seems like things draw properly.

Hmm, could’ve sworn we needed that there... This could all be down to
me misunderstanding something.

*checks*

Oh dammit. Yes. Looks like that flush display is not needed at all. I
could’ve sworn it was, but perhaps some other change fixed that...

Attached is a patch with this and a couple of other small graphics
fixes (I think this breaks GNUstep as is, but I’ll look at that
later). Can you please give it a go and see if there are any problems?
-- 
Alan Third

[-- Attachment #2: 0001-Fix-some-NS-drawing-issues-bug-32932.patch --]
[-- Type: text/plain, Size: 4362 bytes --]

From 4758870a4a7ebee44264cceeeeb0687002dccb57 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sun, 14 Oct 2018 19:12:00 +0100
Subject: [PATCH] Fix some NS drawing issues (bug#32932)

* src/nsterm.m (ns_clip_to_rect):
(ns_reset_clipping): Remove gsaved variable and associated code.
(ns_flush_display): Remove function.
(ns_copy_bits): use translateRectsNeedingDisplayInRect:by: to copy any
pending drawing actions along with the image.
([EmacsView windowWillResize:toSize:]): Remove unneeded call.
---
 src/nsterm.m | 41 +++++++++++++++--------------------------
 1 file changed, 15 insertions(+), 26 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 8c355a89f8..cff77037d4 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -277,7 +277,6 @@ - (NSColor *)colorUsingDefaultColorSpace
 
 /* display update */
 static int ns_window_num = 0;
-static BOOL gsaved = NO;
 static BOOL ns_fake_keydown = NO;
 #ifdef NS_IMPL_COCOA
 static BOOL ns_menu_bar_is_hidden = NO;
@@ -1180,7 +1179,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
             NSRectClipList (r, 2);
           else
             NSRectClip (*r);
-          gsaved = YES;
 
           return YES;
         }
@@ -1204,11 +1202,7 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 {
   NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "ns_reset_clipping");
 
-  if (gsaved)
-    {
-      [[NSGraphicsContext currentContext] restoreGraphicsState];
-      gsaved = NO;
-    }
+  [[NSGraphicsContext currentContext] restoreGraphicsState];
 }
 
 
@@ -1234,19 +1228,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
   return ns_clip_to_rect (f, &clip_rect, 1);
 }
 
-
-static void
-ns_flush_display (struct frame *f)
-/* Force the frame to redisplay.  If areas have previously been marked
-   dirty by setNeedsDisplayInRect (in ns_clip_to_rect), then this will call
-   draw_rect: which will "expose" those areas.  */
-{
-  block_input ();
-  [FRAME_NS_VIEW (f) displayIfNeeded];
-  unblock_input ();
-}
-
-
 /* ==========================================================================
 
     Visible bell and beep.
@@ -2710,6 +2691,8 @@ so some key presses (TAB) are swallowed by the system. */
 static void
 ns_copy_bits (struct frame *f, NSRect src, NSRect dest)
 {
+  NSSize delta = NSMakeSize (dest.origin.x - src.origin.x,
+                             dest.origin.y - src.origin.y)
   NSTRACE ("ns_copy_bits");
 
   if (FRAME_NS_VIEW (f))
@@ -2718,10 +2701,17 @@ so some key presses (TAB) are swallowed by the system. */
 
       /* FIXME: scrollRect:by: is deprecated in macOS 10.14.  There is
          no obvious replacement so we may have to come up with our own.  */
-      [FRAME_NS_VIEW (f) scrollRect: src
-                                 by: NSMakeSize (dest.origin.x - src.origin.x,
-                                                 dest.origin.y - src.origin.y)];
-      [FRAME_NS_VIEW (f) setNeedsDisplay:YES];
+      [FRAME_NS_VIEW (f) scrollRect: src by: delta];
+
+      /* As far as I can tell from the documentation, scrollRect:by:,
+         above, should copy the dirty rectangles from our source
+         rectangle to our destination, however it appears it clips the
+         operation to src.  As a result we need to use
+         translateRectsNeedingDisplayInRect:by: below, and we have to
+         union src and dest so it can pick up the dirty rectangles,
+         and place them, as it also clips to the rectangle.  */
+      [FRAME_NS_VIEW (f) translateRectsNeedingDisplayInRect:NSUnionRect (src, dest)
+                                                         by:delta];
     }
 }
 
@@ -4977,7 +4967,7 @@ static Lisp_Object ns_string_to_lispmod (const char *s)
   ns_after_update_window_line,
   ns_update_window_begin,
   ns_update_window_end,
-  ns_flush_display, /* flush_display */
+  0, /* flush_display */
   x_clear_window_mouse_face,
   x_get_glyph_overhangs,
   x_fix_overlapping_area,
@@ -7046,7 +7036,6 @@ - (NSSize)windowWillResize: (NSWindow *)sender toSize: (NSSize)frameSize
         size_title = xmalloc (strlen (old_title) + 40);
 	esprintf (size_title, "%s  —  (%d x %d)", old_title, cols, rows);
         [window setTitle: [NSString stringWithUTF8String: size_title]];
-        [window display];
         xfree (size_title);
       }
   }
-- 
2.18.0

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 14, 2018 at 11:20:17 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> Attached is a patch with this and a couple of other small graphics
> fixes (I think this breaks GNUstep as is, but I’ll look at that
> later). Can you please give it a go and see if there are any problems?

Will do, thanks. FYI Boris, if you’re on master, you’ll need to cherry
pick a6ab8db3a3 as well before this applies cleanly.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Boris Buliga]

Will check. Thank you for additional instructions :)

Cheers,
Boris

On 14 Oct 2018, at 23:17, Aaron Jensen wrote:

> On October 14, 2018 at 11:20:17 AM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
>
>> Attached is a patch with this and a couple of other small graphics
>> fixes (I think this breaks GNUstep as is, but I’ll look at that
>> later). Can you please give it a go and see if there are any problems?
>
> Will do, thanks. FYI Boris, if you’re on master, you’ll need to cherry
> pick a6ab8db3a3 as well before this applies cleanly.
>
> Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Boris Buliga]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

Alan,

Thank you for the patch. After I've applied it, I didn't experience the
problem again. But the working day has just started, so let's see how it
goes.

P. S. Aaron, thanks for the hint with commit a6ab8db3a3.

On Tue, 16 Oct 2018 at 07:53, Boris Buliga <boris@d12frosted.io> wrote:

> Will check. Thank you for additional instructions :)
>
> Cheers,
> Boris
>
> On 14 Oct 2018, at 23:17, Aaron Jensen wrote:
>
> > On October 14, 2018 at 11:20:17 AM, Alan Third
> > (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> >
> >> Attached is a patch with this and a couple of other small graphics
> >> fixes (I think this breaks GNUstep as is, but I’ll look at that
> >> later). Can you please give it a go and see if there are any problems?
> >
> > Will do, thanks. FYI Boris, if you’re on master, you’ll need to cherry
> > pick a6ab8db3a3 as well before this applies cleanly.
> >
> > Aaron
>


-- 
Cheers,
Boris

[-- Attachment #2: Type: text/html, Size: 1622 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 15, 2018 at 9:53:30 PM, Boris Buliga
(boris@d12frosted.io(mailto:boris@d12frosted.io)) wrote:

> Will check. Thank you for additional instructions :)

No problem.

> > On October 14, 2018 at 11:20:17 AM, Alan Third
> > (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> >
> >> Attached is a patch with this and a couple of other small graphics
> >> fixes (I think this breaks GNUstep as is, but I’ll look at that
> >> later). Can you please give it a go and see if there are any problems?

It seems to work well for me as well. I’ve seen at least one full
frame blank flash but that’s it. It’s been much improved. Unless there
are other concerns, I’d suggest merging.

The other thing that I see sometimes and I don’t know if it is related
is that the menu bar flickers. I don’t know how Emacs could do that so
it could be an OS level bug, but I wanted to mention it in case it
jogged any ideas.

Cheers,

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 16, 2018 at 12:04:19 PM, Aaron Jensen
(aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:
> The other thing that I see sometimes and I don’t know if it is related is that the menu bar flickers. I don’t know how Emacs could do that so it could be an OS level bug, but I wanted to mention it in case it jogged any ideas.

I definitely still see render errors. I don’t have a way to reproduce
them, but I was able to capture a screenshot:

https://cl.ly/9065281385cf/Image%202018-10-19%20at%209.20.34%20AM.png

I believe everything was blank until I started to do next lines. Every
line the point touched painted.

I still think that the patch is better than what’s on master, but it’s
not perfect just yet.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Fri, Oct 19, 2018 at 09:26:56AM -0700, Aaron Jensen wrote:
> On October 16, 2018 at 12:04:19 PM, Aaron Jensen
> (aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:
> > The other thing that I see sometimes and I don’t know if it is
> > related is that the menu bar flickers. I don’t know how Emacs
> > could do that so it could be an OS level bug, but I wanted to
> > mention it in case it jogged any ideas.

Well, the GNUstep version flickers the menu two or three times every
repaint. I think it’s because there’s some code forcing an update of
the menus to work around a problem with them not updating correctly
when required.

The menus definitely need a fair bit of work done to them. I think
they’re a little overly complex, but that may have been done to match
up with how Emacs handles them. I need to investigate it more.

> I definitely still see render errors. I don’t have a way to reproduce
> them, but I was able to capture a screenshot:
> 
> https://cl.ly/9065281385cf/Image%202018-10-19%20at%209.20.34%20AM.png

Does it actually look like that? With the strange blocks? It looks
like there’s some weird resizing/resampling thing going on...

> I believe everything was blank until I started to do next lines. Every
> line the point touched painted.

That makes sense because of how the cursor code marks entire lines as
dirty. If it was drawing correctly then I’d fix it, but there’s no
point just now.

> I still think that the patch is better than what’s on master, but it’s
> not perfect just yet.

I understand Eli’s planning on a freeze for 26.2 soon, so if I’ve not
got anything better than this at that point I’ll make sure it’s
included.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Fri, Oct 19, 2018 at 11:48 AM Alan Third <alan@idiocy.org> wrote:
>
> The menus definitely need a fair bit of work done to them. I think
> they’re a little overly complex, but that may have been done to match
> up with how Emacs handles them. I need to investigate it more.

Ok, sounds good.

> > https://cl.ly/9065281385cf/Image%202018-10-19%20at%209.20.34%20AM.png
>
> Does it actually look like that? With the strange blocks? It looks
> like there’s some weird resizing/resampling thing going on...

No, that's me anonymizing source I can't share :)

> That makes sense because of how the cursor code marks entire lines as
> dirty. If it was drawing correctly then I’d fix it, but there’s no
> point just now.

Sorry, fix which, and what drawing correctly? I didn't think it
repainting the cursor line is a problem (especially since I use
global-hl-line-mode). But maybe you meant something else.

> I understand Eli’s planning on a freeze for 26.2 soon, so if I’ve not
> got anything better than this at that point I’ll make sure it’s
> included.

Understood.

Thanks,

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Fri, Oct 19, 2018 at 12:24:33PM -0700, Aaron Jensen wrote:
> On Fri, Oct 19, 2018 at 11:48 AM Alan Third <alan@idiocy.org> wrote:
> > > https://cl.ly/9065281385cf/Image%202018-10-19%20at%209.20.34%20AM.png
> >
> > Does it actually look like that? With the strange blocks? It looks
> > like there’s some weird resizing/resampling thing going on...
> 
> No, that's me anonymizing source I can't share :)

Oh, thank goodness! :)

> > That makes sense because of how the cursor code marks entire lines as
> > dirty. If it was drawing correctly then I’d fix it, but there’s no
> > point just now.
> 
> Sorry, fix which, and what drawing correctly? I didn't think it
> repainting the cursor line is a problem (especially since I use
> global-hl-line-mode). But maybe you meant something else.

Sorry, I’m just confusing things. We’re redrawing more than we need to
at the moment. It’s not really a problem.

Can you try removing

    ns_clear_frame_area (emacsframe, x, y, width, height);

from drawRect: in nsterm.m? It may result in the background not being
redrawn correctly in some places, but I *think* it’s redundant, and
it’s possible for it to clear a section of screen and then
expose_frame to decide not to redraw anything.

This shouldn’t happen as the only reason I know for expose_frame to
not redraw is if there’s a redisplay coming up, in which case
redisplay should mark the whole frame as needing redrawn anyway. But
perhaps there’s some situation where it doesn’t draw and there’s no
immediate redisplay.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 20, 2018 at 1:04:47 PM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> Can you try removing
>
> ns_clear_frame_area (emacsframe, x, y, width, height);
>
> from drawRect: in nsterm.m? It may result in the background not being
> redrawn correctly in some places, but I *think* it’s redundant, and
> it’s possible for it to clear a section of screen and then
> expose_frame to decide not to redraw anything.
>
> This shouldn’t happen as the only reason I know for expose_frame to
> not redraw is if there’s a redisplay coming up, in which case
> redisplay should mark the whole frame as needing redrawn anyway. But
> perhaps there’s some situation where it doesn’t draw and there’s no
> immediate redisplay.

So far so good. I don’t believe I’ve seen aberrant paints/clears. I’ll
keep using it for another week or so and report back.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Mon, Oct 22, 2018 at 07:15:03PM -0700, Aaron Jensen wrote:
> On October 20, 2018 at 1:04:47 PM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> 
> > Can you try removing
> >
> > ns_clear_frame_area (emacsframe, x, y, width, height);
> >
> > from drawRect: in nsterm.m? It may result in the background not being
> > redrawn correctly in some places, but I *think* it’s redundant, and
> > it’s possible for it to clear a section of screen and then
> > expose_frame to decide not to redraw anything.
> >
> > This shouldn’t happen as the only reason I know for expose_frame to
> > not redraw is if there’s a redisplay coming up, in which case
> > redisplay should mark the whole frame as needing redrawn anyway. But
> > perhaps there’s some situation where it doesn’t draw and there’s no
> > immediate redisplay.
> 
> So far so good. I don’t believe I’ve seen aberrant paints/clears. I’ll
> keep using it for another week or so and report back.

I’ve pushed a slight variant of this change to emacs-26. I’ve
witnessed a very rare flicker of the modeline and the line containing
the cursor in other windows while scrolling, but I can’t replicate it
consistently.

I opened a large file (xdisp.c), set the frame up like so:
M-f10 C-x 3 C-x 2, and scrolled the top left window up and down as
fast as possible.

Thanks for your help with this.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 24, 2018 at 3:42:47 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> I’ve pushed a slight variant of this change to emacs-26. I’ve
> witnessed a very rare flicker of the modeline and the line containing
> the cursor in other windows while scrolling, but I can’t replicate it
> consistently.

I am definitely seeing the flicker on the current line. It happens
occasionally when my emacs is idle (probably not truly idle). I see it
sometimes when I tell emacs to do something that is a thread blocking
operation (like loading some autoloaded lisp for the first time). It’s
as if it clears the current line and then immediately blocks the
rendering thread before it gets a chance to rerender the line. As soon
as Emacs is done doing whatever it was doing, the line rerenders.

No clue if that helps, but if there’s anything you want to try, I’ll
be able to let you know if it fixes it :)

Cheers,

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

On Sun, Oct 28, 2018 at 07:18:04PM -0700, Aaron Jensen wrote:
> On October 24, 2018 at 3:42:47 AM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> 
> > I’ve pushed a slight variant of this change to emacs-26. I’ve
> > witnessed a very rare flicker of the modeline and the line containing
> > the cursor in other windows while scrolling, but I can’t replicate it
> > consistently.
> 
> I am definitely seeing the flicker on the current line. It happens
> occasionally when my emacs is idle (probably not truly idle). I see it
> sometimes when I tell emacs to do something that is a thread blocking
> operation (like loading some autoloaded lisp for the first time). It’s
> as if it clears the current line and then immediately blocks the
> rendering thread before it gets a chance to rerender the line. As soon
> as Emacs is done doing whatever it was doing, the line rerenders.
> 
> No clue if that helps, but if there’s anything you want to try, I’ll
> be able to let you know if it fixes it :)

One more go. I don’t think I’ve seen the cursor line flicker after
installing this.

Simply, all I’ve done is stop making it redraw the entire line the
cursor is on. That should stop any flicker of the line text caused by
redrawing the cursor, but won’t stop any flicker of the cursor itself,
although I’ve not seen it flicker.

There’s a bit more in here to do with drawing the fringe bitmaps,
because that was the only other place ns_clip_to_row was being used,
so I’ve removed it from there too.
-- 
Alan Third

[-- Attachment #2: 0001-Fix-more-drawing-bugs-in-NS-port-bug-32932.patch --]
[-- Type: text/plain, Size: 7070 bytes --]

From 95160c34b4f41e867761f29239db02e8e7232bbe Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Mon, 29 Oct 2018 15:37:35 +0000
Subject: [PATCH] Fix more drawing bugs in NS port (bug#32932)

* src/nsterm.m (ns_row_rect): New function.
(ns_clip_to_row): Remove function.
(ns_copy_bits): Fix mistake.
(ns_draw_fringe_bitmap): Stop using ns_clip_to_row.
(ns_draw_window_cursor): Stop using ns_clip_to_row and move
ns_reset_clipping to try and force cursor drawing to be atomic.
---
 src/nsterm.m | 105 +++++++++++++++++++++++++++++----------------------
 1 file changed, 59 insertions(+), 46 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 4b5d025ee3..39a7b25f60 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -796,6 +796,27 @@ Free a pool and temporary objects it refers to (callable from C)
 }
 
 
+static NSRect
+ns_row_rect (struct window *w, struct glyph_row *row,
+               enum glyph_row_area area)
+/* Get the row as an NSRect.  */
+{
+  struct frame *f = XFRAME (WINDOW_FRAME (w));
+  NSRect rect;
+  int window_x, window_y, window_width;
+
+  window_box (w, area, &window_x, &window_y, &window_width, 0);
+
+  rect.origin.x = window_x;
+  rect.origin.y = WINDOW_TO_FRAME_PIXEL_Y (w, max (0, row->y));
+  rect.origin.y = max (rect.origin.y, window_y);
+  rect.size.width = window_width;
+  rect.size.height = row->visible_height;
+
+  return rect;
+}
+
+
 /* ==========================================================================
 
     Focus (clipping) and screen update
@@ -1206,28 +1227,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 }
 
 
-static BOOL
-ns_clip_to_row (struct window *w, struct glyph_row *row,
-		enum glyph_row_area area, BOOL gc)
-/* --------------------------------------------------------------------------
-     Internal (but parallels other terms): Focus drawing on given row
-   -------------------------------------------------------------------------- */
-{
-  struct frame *f = XFRAME (WINDOW_FRAME (w));
-  NSRect clip_rect;
-  int window_x, window_y, window_width;
-
-  window_box (w, area, &window_x, &window_y, &window_width, 0);
-
-  clip_rect.origin.x = window_x;
-  clip_rect.origin.y = WINDOW_TO_FRAME_PIXEL_Y (w, max (0, row->y));
-  clip_rect.origin.y = max (clip_rect.origin.y, window_y);
-  clip_rect.size.width = window_width;
-  clip_rect.size.height = row->visible_height;
-
-  return ns_clip_to_rect (f, &clip_rect, 1);
-}
-
 /* ==========================================================================
 
     Visible bell and beep.
@@ -2692,7 +2691,7 @@ so some key presses (TAB) are swallowed by the system. */
 ns_copy_bits (struct frame *f, NSRect src, NSRect dest)
 {
   NSSize delta = NSMakeSize (dest.origin.x - src.origin.x,
-                             dest.origin.y - src.origin.y)
+                             dest.origin.y - src.origin.y);
   NSTRACE ("ns_copy_bits");
 
   if (FRAME_NS_VIEW (f))
@@ -2911,6 +2910,9 @@ so some key presses (TAB) are swallowed by the system. */
   struct face *face = p->face;
   static EmacsImage **bimgs = NULL;
   static int nBimgs = 0;
+  NSRect clearRect = NSZeroRect;
+  NSRect imageRect = NSZeroRect;
+  NSRect rowRect = ns_row_rect (w, row, ANY_AREA);
 
   NSTRACE_WHEN (NSTRACE_GROUP_FRINGE, "ns_draw_fringe_bitmap");
   NSTRACE_MSG ("which:%d cursor:%d overlay:%d width:%d height:%d period:%d",
@@ -2925,25 +2927,40 @@ so some key presses (TAB) are swallowed by the system. */
       nBimgs = max_used_fringe_bitmap;
     }
 
-  /* Must clip because of partially visible lines.  */
-  if (ns_clip_to_row (w, row, ANY_AREA, YES))
+  /* Work out the rectangle we will composite into.  */
+  if (p->which)
+    imageRect = NSMakeRect (p->x, p->y, p->wd, p->h);
+
+  /* Work out the rectangle we will need to clear.  Because we're
+     compositing rather than blitting, we need to clear the area under
+     the image regardless of anything else.  */
+  if (!p->overlay_p)
+    {
+      clearRect = NSMakeRect (p->bx, p->by, p->nx, p->ny);
+      clearRect = NSUnionRect (clearRect, imageRect);
+    }
+  else
     {
-      if (!p->overlay_p)
+      clearRect = imageRect;
+    }
+
+  /* Handle partially visible rows.  */
+  clearRect = NSIntersectionRect (clearRect, rowRect);
+
+  /* The visible portion of imageRect will always be contained within
+     clearRect.  */
+  if (ns_clip_to_rect (f, &clearRect, 1))
+    {
+      if (! NSIsEmptyRect (clearRect))
         {
-          int bx = p->bx, by = p->by, nx = p->nx, ny = p->ny;
+          NSTRACE_RECT ("clearRect", clearRect);
 
-          if (bx >= 0 && nx > 0)
-            {
-              NSRect r = NSMakeRect (bx, by, nx, ny);
-              NSRectClip (r);
-              [ns_lookup_indexed_color (face->background, f) set];
-              NSRectFill (r);
-            }
+          [ns_lookup_indexed_color(face->background, f) set];
+          NSRectFill (clearRect);
         }
 
       if (p->which)
         {
-          NSRect r = NSMakeRect (p->x, p->y, p->wd, p->h);
           EmacsImage *img = bimgs[p->which - 1];
 
           if (!img)
@@ -2964,13 +2981,6 @@ so some key presses (TAB) are swallowed by the system. */
               xfree (cbits);
             }
 
-          NSTRACE_RECT ("r", r);
-
-          NSRectClip (r);
-          /* Since we composite the bitmap instead of just blitting it, we need
-             to erase the whole background.  */
-          [ns_lookup_indexed_color(face->background, f) set];
-          NSRectFill (r);
 
           {
             NSColor *bm_color;
@@ -2990,7 +3000,7 @@ so some key presses (TAB) are swallowed by the system. */
 
           NSTRACE_RECT ("fromRect", fromRect);
 
-          [img drawInRect: r
+          [img drawInRect: imageRect
                  fromRect: fromRect
                 operation: NSCompositingOperationSourceOver
                  fraction: 1.0
@@ -2998,7 +3008,7 @@ so some key presses (TAB) are swallowed by the system. */
                     hints: nil];
 #else
           {
-            NSPoint pt = r.origin;
+            NSPoint pt = imageRect.origin;
             pt.y += p->h;
             [img compositeToPoint: pt operation: NSCompositingOperationSourceOver];
           }
@@ -3088,7 +3098,9 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
   r.size.width = w->phys_cursor_width;
 
   /* Prevent the cursor from being drawn outside the text area.  */
-  if (ns_clip_to_row (w, glyph_row, TEXT_AREA, NO))
+  r = NSIntersectionRect (r, ns_row_rect (w, glyph_row, TEXT_AREA));
+
+  if (ns_clip_to_rect (f, &r, 1))
     {
       face = FACE_FROM_ID_OR_NULL (f, phys_cursor_glyph->face_id);
       if (face && NS_FACE_BACKGROUND (face)
@@ -3128,11 +3140,12 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
           NSRectFill (s);
           break;
         }
-      ns_reset_clipping (f);
 
       /* draw the character under the cursor */
       if (cursor_type != NO_CURSOR)
         draw_phys_cursor_glyph (w, glyph_row, DRAW_CURSOR);
+
+      ns_reset_clipping (f);
     }
 }
 
-- 
2.18.0

bug#32932: 27.0.50; render bugs on macOS Mojave

[Boris Buliga]

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

Alan,

Thank you for the patch. I will also give it a try because I experience
flickering from time to time.

On Mon, 29 Oct 2018 at 18:09, Alan Third <alan@idiocy.org> wrote:

> On Sun, Oct 28, 2018 at 07:18:04PM -0700, Aaron Jensen wrote:
> > On October 24, 2018 at 3:42:47 AM, Alan Third
> > (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> >
> > > I’ve pushed a slight variant of this change to emacs-26. I’ve
> > > witnessed a very rare flicker of the modeline and the line containing
> > > the cursor in other windows while scrolling, but I can’t replicate it
> > > consistently.
> >
> > I am definitely seeing the flicker on the current line. It happens
> > occasionally when my emacs is idle (probably not truly idle). I see it
> > sometimes when I tell emacs to do something that is a thread blocking
> > operation (like loading some autoloaded lisp for the first time). It’s
> > as if it clears the current line and then immediately blocks the
> > rendering thread before it gets a chance to rerender the line. As soon
> > as Emacs is done doing whatever it was doing, the line rerenders.
> >
> > No clue if that helps, but if there’s anything you want to try, I’ll
> > be able to let you know if it fixes it :)
>
> One more go. I don’t think I’ve seen the cursor line flicker after
> installing this.
>
> Simply, all I’ve done is stop making it redraw the entire line the
> cursor is on. That should stop any flicker of the line text caused by
> redrawing the cursor, but won’t stop any flicker of the cursor itself,
> although I’ve not seen it flicker.
>
> There’s a bit more in here to do with drawing the fringe bitmaps,
> because that was the only other place ns_clip_to_row was being used,
> so I’ve removed it from there too.
> --
> Alan Third
>


-- 
Cheers,
Boris

[-- Attachment #2: Type: text/html, Size: 2520 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 29, 2018 at 9:09:48 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> One more go. I don’t think I’ve seen the cursor line flicker after
> installing this.
>
> Simply, all I’ve done is stop making it redraw the entire line the
> cursor is on. That should stop any flicker of the line text caused by
> redrawing the cursor, but won’t stop any flicker of the cursor itself,
> although I’ve not seen it flicker.

I’ve got a consistent repro on my config with this patch. If I start
emacs then open a dired buffer in a dir that has images in it, then
hit return on one of the images, the current line goes blank while the
image loads. If I kill the buffer and reopen the same one it does not
repro.

I cannot reproduce this in emacs -Q as it’s much faster than whatever
my config is doing whenever I open an image.

That said, I haven’t seen any line flickers yet aside from that. I’ll
keep trying it out and report back.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Boris Buliga]

[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]

Hi,

It feels much better! Thank you.

I run only into one issue. I had two windows in a buffer and invoked
multi-term, which created a new window at the bottom. The thing is - all
windows except the new one where completely empty (except for cursor).
Can't reproduce it anymore though. Quickly resolved by actions in the
multi-term.

Unfortunately, I could not make a screenshot (I miss clicked and forced
refresh).


On Tue, 30 Oct 2018 at 07:56, Aaron Jensen <aaronjensen@gmail.com> wrote:

> On October 29, 2018 at 9:09:48 AM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
>
> > One more go. I don’t think I’ve seen the cursor line flicker after
> > installing this.
> >
> > Simply, all I’ve done is stop making it redraw the entire line the
> > cursor is on. That should stop any flicker of the line text caused by
> > redrawing the cursor, but won’t stop any flicker of the cursor itself,
> > although I’ve not seen it flicker.
>
> I’ve got a consistent repro on my config with this patch. If I start
> emacs then open a dired buffer in a dir that has images in it, then
> hit return on one of the images, the current line goes blank while the
> image loads. If I kill the buffer and reopen the same one it does not
> repro.
>
> I cannot reproduce this in emacs -Q as it’s much faster than whatever
> my config is doing whenever I open an image.
>
> That said, I haven’t seen any line flickers yet aside from that. I’ll
> keep trying it out and report back.
>
> Aaron
>


-- 
Cheers,
Boris

[-- Attachment #2: Type: text/html, Size: 2297 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Mon, Oct 29, 2018 at 10:56:34PM -0700, Aaron Jensen wrote:
> I’ve got a consistent repro on my config with this patch. If I start
> emacs then open a dired buffer in a dir that has images in it, then
> hit return on one of the images, the current line goes blank while the
> image loads. If I kill the buffer and reopen the same one it does not
> repro.
> 
> I cannot reproduce this in emacs -Q as it’s much faster than whatever
> my config is doing whenever I open an image.

I was hoping I’d manage to get something going with this but it’s
completely fine here. Does the line blank, then redraw, then the image
loads in its new buffer?

Something is blanking the line. There are only so many places where
that happens so in theory it should be relatively straight‐forward to
find the place in question. Perhaps start by commenting out the
NSRectFill commands in ns_clear_frame and ns_clear_frame_area.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Tue, Oct 30, 2018 at 05:35:05PM +0200, Boris Buliga wrote:
> Hi,
> 
> It feels much better! Thank you.
> 
> I run only into one issue. I had two windows in a buffer and invoked
> multi-term, which created a new window at the bottom. The thing is - all
> windows except the new one where completely empty (except for cursor).
> Can't reproduce it anymore though. Quickly resolved by actions in the
> multi-term.
> 
> Unfortunately, I could not make a screenshot (I miss clicked and forced
> refresh).

I am really stumped by all these blanks...

A long shot: are either of you using scrollbars?
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 31, 2018 at 2:59:54 PM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> A long shot: are either of you using scrollbars?

I’m not. I haven’t had a chance to try debugging yet, but I’ll give it
a shot soon.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

On October 31, 2018 at 10:13:01 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> I was hoping I’d manage to get something going with this but it’s
> completely fine here. Does the line blank, then redraw, then the image
> loads in its new buffer?

AFAICT it blanks, then loads the buffer. If I go back to the previous
buffer the line is filled in. If I attempt to load the same image
again, it does not blank. It’s only the first time for each image.

> Something is blanking the line. There are only so many places where
> that happens so in theory it should be relatively straight‐forward to
> find the place in question. Perhaps start by commenting out the
> NSRectFill commands in ns_clear_frame and ns_clear_frame_area.

I commented out every single NSRectFill and it still did it. It’s
fast, but gif attached.

I tried commenting out the setNeedsDisplay but that breaks rendering entirely.

[-- Attachment #2: line.gif --]
[-- Type: image/gif, Size: 33135 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

> On October 31, 2018 at 10:13:01 AM, Alan Third (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> > Something is blanking the line. There are only so many places where
> > that happens so in theory it should be relatively straight‐forward to
> > find the place in question. Perhaps start by commenting out the
> > NSRectFill commands in ns_clear_frame and ns_clear_frame_area.
>
> I commented out every single NSRectFill and it still did it. It’s fast, but gif attached.
>
> I tried commenting out the setNeedsDisplay but that breaks rendering entirely.

This is a trace from when it happens with all groups enabled. Not sure
fi it helps...

nsterm.m  : 6202: [  517]  [EmacsView keyDown:]
nsimage.m :   61: [  518]  ns_image_for_XPM
nsterm.m  : 2352: [  519]  ns_lisp_to_color
nsterm.m  : 2231: [  520]  | ns_get_color(#FFEB95, **)
nsterm.m  : 3172: [  521]  ns_draw_window_cursor
nsterm.m  : 3172: [  522]  ns_draw_window_cursor
nsterm.m  : 3172: [  523]  ns_draw_window_cursor
nsterm.m  : 1245: [  524]  | ns_clip_to_rect
nsterm.m  : 1248: [  525]  | +--- r: (X:464 Y:76)/(W:8 H:19)
nsterm.m  : 1265: [  526]  | +--- r: (X:464 Y:76)/(W:8 H:19)
nsterm.m  : 3172: [  527]  ns_draw_window_cursor
nsfns.m   :  525: [  528]  x_implicitly_set_name
nsfns.m   :  475: [  529]  | ns_set_represented_filename
nsfns.m   :  432: [  530]  | ns_set_name
nsmenu.m  :  116: [  531]  ns_update_menubar
nsterm.m  : 4924: [  532]  ns_condemn_scroll_bars
nsterm.m  : 2352: [  533]  ns_lisp_to_color
nsterm.m  : 2231: [  534]  | ns_get_color(#ffffffffffff, **)
nsterm.m  : 2352: [  535]  ns_lisp_to_color
nsterm.m  : 2231: [  536]  | ns_get_color(#FFEB95, **)
nsimage.m :   61: [  537]  ns_image_for_XPM
nsterm.m  : 4973: [  538]  ns_judge_scroll_bars

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 31, 2018 at 9:58:59 PM, Aaron Jensen
(aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:

> > On October 31, 2018 at 10:13:01 AM, Alan Third (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> > > Something is blanking the line. There are only so many places where
> > > that happens so in theory it should be relatively straight‐forward to
> > > find the place in question. Perhaps start by commenting out the
> > > NSRectFill commands in ns_clear_frame and ns_clear_frame_area.
> >
> > I commented out every single NSRectFill and it still did it. It’s fast, but gif attached.
> >
> > I tried commenting out the setNeedsDisplay but that breaks rendering entirely.


Okay, the blank does not occur if I comment out this line:

  w->phys_cursor_on_p = on_p;

Hopefully that’s a helpful clue :)

The other place this blank happens is when opening a buffer from ivy.
The mini buffer blanks. It seems that has something to do w/ clearing
cursors from the non-active windows, perhaps it’s being a little
overzealous in its clearing and it doesn’t get a chance to paint
before the cpu starts churning.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Boris Buliga]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

Yes, I've also noticed blanks with ivy.

But for sure this patch is a HUGE improvement. I had to work a little bit
on a
machine where I didn't install this patch and I have encountered a lot of
random
blanks.

--------------------------------------------------------------------------------

Aaron,

I will hopefully be able to test with the following line commented out.

w->phys_cursor_on_p = on_p;


On Thu, 1 Nov 2018 at 07:11, Aaron Jensen <aaronjensen@gmail.com> wrote:

> On October 31, 2018 at 9:58:59 PM, Aaron Jensen
> (aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:
>
> > > On October 31, 2018 at 10:13:01 AM, Alan Third (alan@idiocy.org
> (mailto:alan@idiocy.org)) wrote:
> > > > Something is blanking the line. There are only so many places where
> > > > that happens so in theory it should be relatively straight‐forward to
> > > > find the place in question. Perhaps start by commenting out the
> > > > NSRectFill commands in ns_clear_frame and ns_clear_frame_area.
> > >
> > > I commented out every single NSRectFill and it still did it. It’s
> fast, but gif attached.
> > >
> > > I tried commenting out the setNeedsDisplay but that breaks rendering
> entirely.
>
>
> Okay, the blank does not occur if I comment out this line:
>
>   w->phys_cursor_on_p = on_p;
>
> Hopefully that’s a helpful clue :)
>
> The other place this blank happens is when opening a buffer from ivy.
> The mini buffer blanks. It seems that has something to do w/ clearing
> cursors from the non-active windows, perhaps it’s being a little
> overzealous in its clearing and it doesn’t get a chance to paint
> before the cpu starts churning.
>
> Aaron
>


-- 
Cheers,
Boris

[-- Attachment #2: Type: text/html, Size: 2720 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On October 31, 2018 at 11:13:53 PM, Boris Buliga
(boris@d12frosted.io(mailto:boris@d12frosted.io)) wrote:

> Yes, I've also noticed blanks with ivy.
>
> But for sure this patch is a HUGE improvement. I had to work a little bit on a
> machine where I didn't install this patch and I have encountered a lot of random
> blanks.
>
>
> --------------------------------------------------------------------------------
>
> Aaron,
>
> I will hopefully be able to test with the following line commented out.
>
> w->phys_cursor_on_p = on_p;

Just commenting that out will cause the cursor to ghost, but it fixes
the problem for me otherwise. Tracing further, it seems that that
getting set causes erase_phys_cursor to get called, which ultimately
calls draw_phys_cursor_glyph, which calls draw_glyphs, which I believe
is what is blanking the line. It appears to be more than just
redrawing the glyph under the cursor.

Another clue is that it appear to only blank from where the cursor is
to the end of the line. Anything before that isn’t cleared.

I’m sure I’m at the end of my depth here w/o diving a lot deeper.
Hopefully this flurry of emails points you in the right direction,
Alan. Thanks!

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Wed, 31 Oct 2018 23:51:42 -0700
> Cc: Alan Third <alan@idiocy.org>, 32932@debbugs.gnu.org
> 
> getting set causes erase_phys_cursor to get called, which ultimately
> calls draw_phys_cursor_glyph, which calls draw_glyphs, which I believe
> is what is blanking the line. It appears to be more than just
> redrawing the glyph under the cursor.
> 
> Another clue is that it appear to only blank from where the cursor is
> to the end of the line. Anything before that isn’t cleared.

Can you find the reason for that?  In general, redrawing the cursor
should only redraw a single character, and sometimes the two adjacent
ones.  It shouldn't redraw more than that.

From what you describe, it sounds like the problem is in the logic
that determines which parts to redraw, see update_text_area in
dispnew.c.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 1, 2018 at 11:12:14 AM, Eli Zaretskii
(eliz@gnu.org(mailto:eliz@gnu.org)) wrote:

> Can you find the reason for that? In general, redrawing the cursor
> should only redraw a single character, and sometimes the two adjacent
> ones. It shouldn't redraw more than that.
>
> From what you describe, it sounds like the problem is in the logic
> that determines which parts to redraw, see update_text_area in
> dispnew.c.

dispnew.c redraws up to the end of the line in many situations. I
added the following logging:

      fprintf (stderr, "clear %d %d %d %d %d %d %d\n", !current_row->enabled_p
               , desired_row->y != current_row->y
               , desired_row->ascent != current_row->ascent
               , desired_row->phys_ascent != current_row->phys_ascent
               , desired_row->phys_height != current_row->phys_height
               , desired_row->visible_height != current_row->visible_height
               , current_row->overlapped_p);
      fprintf (stderr, "desired\t%d\t%d\t%d\t%d\t%d\n"
               , desired_row->y
               , desired_row->ascent
               , desired_row->phys_ascent
               , desired_row->phys_height
               , desired_row->visible_height);
      fprintf (stderr, "current\t%d\t%d\t%d\t%d\t%d\n"
               , current_row->y
               , current_row->ascent
               , current_row->phys_ascent
               , current_row->phys_height
               , current_row->visible_height);

And when this happens, this is what I get:

draw_glyphs x: 56 pos: 7 8
clear 0 0 1 1 1 0 0
desired 0       15      12      16      19
current 0       0       0       19      19
clear 1 0 0 0 0 0 0
desired 637     20      19      26      28
current 637     20      19      26      28
clear 1 0 1 1 1 1 0
desired 0       318     318     637     637
current 0       15      15      19      19
clear 1 0 0 0 0 0 0
desired 0       15      12      16      19
current 0       15      12      16      19

So, the ascent and physics_ascent on the current row are coming back
as 0. Also, the height is different.

That’s causing it to redraw to the end of the line.

AFAICT there are two issues:

1. It’s redrawing to the end of the line unnecessarily.
2. It’s clearing and then doing some other processing before actually painting.

If #1 was fixed, it would perhaps be better, but I wonder if the area
under the cursor would be cleared the same.

I tried changing the condition in update_text_area to just:

if (!current_row->enabled_p)

And it still reproduced, so the ascent stuff above may be a red herring…

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 1 Nov 2018 12:52:43 -0700
> Cc: 32932@debbugs.gnu.org, boris@d12frosted.io, alan@idiocy.org
> 
> dispnew.c redraws up to the end of the line in many situations. I
> added the following logging:
> 
>       fprintf (stderr, "clear %d %d %d %d %d %d %d\n", !current_row->enabled_p
>                , desired_row->y != current_row->y
>                , desired_row->ascent != current_row->ascent
>                , desired_row->phys_ascent != current_row->phys_ascent
>                , desired_row->phys_height != current_row->phys_height
>                , desired_row->visible_height != current_row->visible_height
>                , current_row->overlapped_p);
>       fprintf (stderr, "desired\t%d\t%d\t%d\t%d\t%d\n"
>                , desired_row->y
>                , desired_row->ascent
>                , desired_row->phys_ascent
>                , desired_row->phys_height
>                , desired_row->visible_height);
>       fprintf (stderr, "current\t%d\t%d\t%d\t%d\t%d\n"
>                , current_row->y
>                , current_row->ascent
>                , current_row->phys_ascent
>                , current_row->phys_height
>                , current_row->visible_height);
> 
> And when this happens, this is what I get:
> 
> draw_glyphs x: 56 pos: 7 8
> clear 0 0 1 1 1 0 0
> desired 0       15      12      16      19
> current 0       0       0       19      19
> clear 1 0 0 0 0 0 0
> desired 637     20      19      26      28
> current 637     20      19      26      28
> clear 1 0 1 1 1 1 0
> desired 0       318     318     637     637
> current 0       15      15      19      19
> clear 1 0 0 0 0 0 0
> desired 0       15      12      16      19
> current 0       15      12      16      19

Thanks, but this is not enough info, I need also to see the actual
contents of the current and the desired rows.  If they are different,
then clearing is justified.  You can display a glyph row in GDB using
the command pgrowx defined in src/.gdbinit.

And which row is the problematic one: the one at Y = 0 or at Y = 637?

The large numbers for the desired row in the 3rd sample look bogus to
me, unless you have a very tall image there.

> So, the ascent and physics_ascent on the current row are coming back
> as 0. Also, the height is different.

Sounds improbable to me.  Are you sure you caught the right rows?

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 1, 2018 at 1:13:05 PM, Eli Zaretskii
(eliz@gnu.org(mailto:eliz@gnu.org)) wrote:

> Thanks, but this is not enough info, I need also to see the actual
> contents of the current and the desired rows. If they are different,
> then clearing is justified. You can display a glyph row in GDB using
> the command pgrowx defined in src/.gdbinit.

Unfortunately, I’m on a Mac, so AFAIK I can only use lldb. I’ll see
what I can figure out.

> And which row is the problematic one: the one at Y = 0 or at Y = 637?

I don’t understand Y=0, is that 0 from where the point is? It’s
probably the 16th row or so from the top.

> The large numbers for the desired row in the 3rd sample look bogus to
> me, unless you have a very tall image there.

It’s a relatively tall image, yeah.

> > So, the ascent and physics_ascent on the current row are coming back
> > as 0. Also, the height is different.
>
> Sounds improbable to me. Are you sure you caught the right rows?

Those are the only things emitted when I pressed enter on the image
file to open it (in this case, from the home buffer with a recent file
list).

I’ll report back as I dig further.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Thu, Nov 01, 2018 at 08:10:53PM +0200, Eli Zaretskii wrote:
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Wed, 31 Oct 2018 23:51:42 -0700
> > Cc: Alan Third <alan@idiocy.org>, 32932@debbugs.gnu.org
> > 
> > getting set causes erase_phys_cursor to get called, which ultimately
> > calls draw_phys_cursor_glyph, which calls draw_glyphs, which I believe
> > is what is blanking the line. It appears to be more than just
> > redrawing the glyph under the cursor.
> > 
> > Another clue is that it appear to only blank from where the cursor is
> > to the end of the line. Anything before that isn’t cleared.
> 
> Can you find the reason for that?  In general, redrawing the cursor
> should only redraw a single character, and sometimes the two adjacent
> ones.  It shouldn't redraw more than that.
> 
> From what you describe, it sounds like the problem is in the logic
> that determines which parts to redraw, see update_text_area in
> dispnew.c.

I’ve done some digging, and I’m pretty tired right now so apologies if
this makes no sense, but it looks as though when Emacs is clearing the
cursor it redraws the entire line that contains the cursor.

This is something being done to a line with the cursor on it:

New dirty rect:(X:10 Y:380)/(W:560 H:14)
Process 40552 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001003ae24a Emacs`ns_clip_to_rect(f=0x00000001030527b0, r=(origin = (x = 10, y = 380), size = (width = 560, height = 14)), n=1) at nsterm.m:1214
   1211	            {
   1212	              fprintf (stderr, "New dirty rect:" NSTRACE_FMT_RECT "\n",
   1213	                         NSTRACE_ARG_RECT(r[i]));
-> 1214	              [view setNeedsDisplayInRect:r[i]];
   1215	            }
   1216	        }
   1217	    }
Target 0: (Emacs) stopped.

I’m printing out the area that Emacs wants to draw (New dirty rect).
It has a width of 560, which is, I think, the full width of the text
area.

The interesting bit of the backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00000001003ae24a Emacs`ns_clip_to_rect(f=0x00000001030527b0, r=(origin = (x = 10, y = 380), size = (width = 560, height = 14)), n=1) at nsterm.m:1214
    frame #1: 0x00000001003e29bf Emacs`ns_draw_glyph_string(s=0x00007ffeefbfbf10) at nsterm.m:4096
    frame #2: 0x000000010006f742 Emacs`draw_glyphs(w=0x0000000103051630, x=388, row=0x00000001030fb100, area=TEXT_AREA, start=53, end=54, hl=DRAW_NORMAL_TEXT, overlaps=0) at xdisp.c:26878
    frame #3: 0x0000000100070c2e Emacs`draw_phys_cursor_glyph(w=0x0000000103051630, row=0x00000001030fb100, hl=DRAW_NORMAL_TEXT) at xdisp.c:29434
    frame #4: 0x0000000100071369 Emacs`erase_phys_cursor(w=0x0000000103051630) at xdisp.c:29570
    frame #5: 0x0000000100071884 Emacs`display_and_set_cursor(w=0x0000000103051630, on=true, hpos=53, vpos=27, x=371, y=378) at xdisp.c:29659
    frame #6: 0x0000000100072243 Emacs`update_window_cursor(w=0x0000000103051630, on=true) at xdisp.c:29714
    frame #7: 0x000000010007204d Emacs`update_cursor_in_window_tree(w=0x0000000103051630, on_p=true) at xdisp.c:29732
    frame #8: 0x0000000100071fd2 Emacs`x_update_cursor(f=0x00000001030527b0, on_p=true) at xdisp.c:29746
    frame #9: 0x00000001003c3b0e Emacs`ns_frame_rehighlight(frame=0x00000001030527b0) at nsterm.m:1508
    frame #10: 0x00000001003c3607 Emacs`-[EmacsView windowDidBecomeKey](self=0x00000001022a8b20, _cmd="windowDidBecomeKey") at nsterm.m:7159
    frame #11: 0x00000001003c3428 Emacs`-[EmacsView windowDidBecomeKey:](self=0x00000001022a8b20, _cmd="windowDidBecomeKey:", notification=@"NSWindowDidBecomeKeyNotification") at nsterm.m:7145

You can see that ‘draw_glyphs’ is being called with start=53 and
end=54, which sounds, to me, like it’s wanting to draw one glyph: the
one under the cursor.

However when it gets round to asking to clip to an area
(ns_clip_to_rect) it’s wanting the entire row.

The parameter s in ns_draw_glyph_string looks right to me (i.e. x, y, width
and height look right for a single glyph):

(lldb) p *s
(glyph_string) $1 = {
  x = 381
  y = 380
  ybase = 391
  width = 7
  background_width = 7
  height = 14
  left_overhang = 0
  right_overhang = 0
  f = 0x00000001030527b0
  w = 0x0000000103051630
  display = 0x0000000000000000
  row = 0x00000001030fb100
  area = TEXT_AREA
  char2b = 0x00007ffeefbfbf00 u"'"
  nchars = 1
  hl = DRAW_NORMAL_TEXT
  face = 0x000000010229e130
  font = 0x000000010427c848
  cmp = 0x0000000000000000
  cmp_id = 0
  cmp_from = 0
  cmp_to = 0
  extends_to_end_of_line_p = false
  background_filled_p = false
  font_not_found_p = false
  stippled_p = false
  for_overlaps = 0
  padding_p = false
  first_glyph = 0x00000001030ed9f0
  img = 0x0000000000000000
  xwidget = 0x0000000000000000
  slice = (x = 0, y = 0, width = 0, height = 0)
  clip_head = 0x0000000000000000
  clip_tail = 0x0000000000000000
  clip = ([0] = (origin = (x = 0, y = 0), size = (width = 0, height = 0)), [1] = (origin = (x = 0, y = 0), size = (width = 0, height = 0)))
  num_clips = 0
  underline_position = 0
  underline_thickness = 0
  next = 0x0000000000000000
  prev = 0x0000000000000000
}

Here’s where it’s working out the clipping rectangle:

(lldb) f 1
frame #1: 0x00000001003e29bf Emacs`ns_draw_glyph_string(s=0x00007ffeefbfbf10) at nsterm.m:4096
   4093	    case CHAR_GLYPH:
   4094	    case COMPOSITE_GLYPH:
   4095	      n = ns_get_glyph_string_clip_rect (s, r);
-> 4096	      if (ns_clip_to_rect (s->f, r, n))
   4097	        {
   4098	          if (s->for_overlaps || (s->cmp_from > 0
   4099	                                  && ! s->first_glyph->u.cmp.automatic))

ns_get_glyph_string_clip_rect is a simple wrapper round
get_glyph_string_clip_rects, so when asked for the clipping rectangle
for a single glyph, it returns a rectangle covering the entire row.

Because we just mark it as dirty and come back to draw it later we do
end up redrawing the entire row.

I don’t know if this is a bug in get_glyph_string_clip_rects, or if
we’re misusing it here and should work out our own clipping rectangles.

I still don’t know why this results in the row being blanked out,
though.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 1 Nov 2018 13:29:40 -0700
> Cc: alan@idiocy.org, 32932@debbugs.gnu.org, boris@d12frosted.io
> 
> On November 1, 2018 at 1:13:05 PM, Eli Zaretskii
> (eliz@gnu.org(mailto:eliz@gnu.org)) wrote:
> 
> > Thanks, but this is not enough info, I need also to see the actual
> > contents of the current and the desired rows. If they are different,
> > then clearing is justified. You can display a glyph row in GDB using
> > the command pgrowx defined in src/.gdbinit.
> 
> Unfortunately, I’m on a Mac, so AFAIK I can only use lldb.

Doesn't the latest GDB compile on macOS?  I thought it did, but
perhaps that's only available in the GDB Git repo.

> I’ll see what I can figure out.

You can, of course, manually type the equivalents of the commands that
GDB uses in pgrowx.

In an Emacs configured with --enable-checking=yes,glyphs, you can also
use the dump-glyph-row command to the same effect.

> > And which row is the problematic one: the one at Y = 0 or at Y = 637?
> 
> I don’t understand Y=0, is that 0 from where the point is? It’s
> probably the 16th row or so from the top.

The Y coordinate is measured from the top of the window.

> > The large numbers for the desired row in the 3rd sample look bogus to
> > me, unless you have a very tall image there.
> 
> It’s a relatively tall image, yeah.

So the problem is with redrawing the cursor in a screen line that
shows a tall image?  Is there any text before and/or after the image
in the same screen line?

> > > So, the ascent and physics_ascent on the current row are coming back
> > > as 0. Also, the height is different.
> >
> > Sounds improbable to me. Are you sure you caught the right rows?
> 
> Those are the only things emitted when I pressed enter on the image
> file to open it (in this case, from the home buffer with a recent file
> list).

If you want to reproduce the flickering, you need to do whatever
causes redisplay after opening the file.  For example, does it flicker
when you move cursor?  Does cursor blinking cause flickering?  Each
one of these should show you the output that tells which parts of the
glyph row is Emacs actually redrawing.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> Date: Thu, 1 Nov 2018 22:55:19 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Aaron Jensen <aaronjensen@gmail.com>, boris@d12frosted.io,
> 	32932@debbugs.gnu.org
> 
> ns_get_glyph_string_clip_rect is a simple wrapper round
> get_glyph_string_clip_rects, so when asked for the clipping rectangle
> for a single glyph, it returns a rectangle covering the entire row.
> 
> Because we just mark it as dirty and come back to draw it later we do
> end up redrawing the entire row.

I think if you are basing the redisplay on marking portions dirty, you
need to include the same logic as in display_and_set_cursor and its
callers.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

[-- Attachment #1.1: Type: text/plain, Size: 2945 bytes --]

On November 3, 2018 at 2:24:10 AM, Eli Zaretskii (eliz@gnu.org(mailto:
eliz@gnu.org)) wrote:

> Doesn't the latest GDB compile on macOS? I thought it did, but
> perhaps that's only available in the GDB Git repo.

It does, it just doesn’t recognize emacs as a valid binary. I’ve tried out
a patch that’s supposed to help with that, but it didn’t work. I’ve give
these instructions a shot: https://stackoverflow.com/a/24918436/11229 and
no luck. I’ve tried for hours and cannot get GDB with emacs on Mojave. I
have gdb working with other built programs (like gdb itself), but when
attempting to run emacs, I either get the code signing error:

Starting program: /Users/aaronjensen/Source/emacs/src/emacs
Unable to find Mach task port for process-id 9979: (os/kern) failure (0x5).

(I’ve code signed gdb, but it only works when running gdb as sudo for a
reason I do not yet know.)

And when running as sudo:

(gdb) set startup-with-shell off
No symbol table is loaded.  Use the "file" command.
(gdb) run
Starting program: /Users/aaronjensen/Source/emacs/src/emacs

Program terminated with signal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.

> > I’ll see what I can figure out.
>
> You can, of course, manually type the equivalents of the commands that
> GDB uses in pgrowx.

That’d require skills I don’t have yet, but I’ll see what I can do.

> In an Emacs configured with --enable-checking=yes,glyphs, you can also
> use the dump-glyph-row command to the same effect.

Would doing this on the row that has the problem even if it is not
currently flickering be useful?

> > > And which row is the problematic one: the one at Y = 0 or at Y = 637?
> >
> > I don’t understand Y=0, is that 0 from where the point is? It’s
> > probably the 16th row or so from the top.
>
> The Y coordinate is measured from the top of the window.

In pixels? In that case, the flickering row is probably the 637 one.

> So the problem is with redrawing the cursor in a screen line that
> shows a tall image? Is there any text before and/or after the image
> in the same screen line?

No, the problem is with the redrawing the cursor on the row that in the
active window *before* the image loads. See the attached gif. Frame 2 of
the gif shows the blank. Frame 1 is before I press enter. When I press
enter, which triggers a find-file on that image, it blanks the line, then
loads the image. If I kill the image buffer and return to the home buffer,
the line has been painted.

> If you want to reproduce the flickering, you need to do whatever
> causes redisplay after opening the file. For example, does it flicker
> when you move cursor? Does cursor blinking cause flickering? Each
> one of these should show you the output that tells which parts of the
> glyph row is Emacs actually redrawing.

The logs I provided were from reproducing the flickering.

[-- Attachment #1.2: Type: text/html, Size: 3965 bytes --]

[-- Attachment #2: line.gif --]
[-- Type: image/gif, Size: 33135 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 1, 2018 at 3:55:23 PM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> I’ve done some digging, and I’m pretty tired right now so apologies if
> this makes no sense, but it looks as though when Emacs is clearing the
> cursor it redraws the entire line that contains the cursor.

Alan, would it help if you had access to my emacs config? Maybe then
you could reproduce the exact thing on your machine?

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sat, 3 Nov 2018 10:56:14 -0700
> Cc: alan@idiocy.org, boris@d12frosted.io, 32932@debbugs.gnu.org
> 
> > Doesn't the latest GDB compile on macOS? I thought it did, but
> > perhaps that's only available in the GDB Git repo. 
> 
> It does, it just doesn’t recognize emacs as a valid binary. I’ve tried out a patch that’s supposed to help with
> that, but it didn’t work. I’ve give these instructions a shot: https://stackoverflow.com/a/24918436/11229 and no
> luck. I’ve tried for hours and cannot get GDB with emacs on Mojave. I have gdb working with other built
> programs (like gdb itself), but when attempting to run emacs, I either get the code signing error:
> 
> Starting program: /Users/aaronjensen/Source/emacs/src/emacs
> Unable to find Mach task port for process-id 9979: (os/kern) failure (0x5).
> 
> (I’ve code signed gdb, but it only works when running gdb as sudo for a reason I do not yet know.)
> 
> And when running as sudo:
> 
> (gdb) set startup-with-shell off
> No symbol table is loaded.  Use the "file" command.
> (gdb) run
> Starting program: /Users/aaronjensen/Source/emacs/src/emacs
> 
> Program terminated with signal SIGTRAP, Trace/breakpoint trap.
> The program no longer exists.

Maybe ask for help on the GDB mailing list.

> > In an Emacs configured with --enable-checking=yes,glyphs, you can also
> > use the dump-glyph-row command to the same effect.
> 
> Would doing this on the row that has the problem even if it is not currently flickering be useful?

If the same row _ever_ flickers, then yes, it will be useful.

> > The Y coordinate is measured from the top of the window.
> 
> In pixels?

Yes.

> > So the problem is with redrawing the cursor in a screen line that
> > shows a tall image? Is there any text before and/or after the image
> > in the same screen line?
> 
> No, the problem is with the redrawing the cursor on the row that in the active window *before* the image
> loads. See the attached gif. Frame 2 of the gif shows the blank. Frame 1 is before I press enter. When I press
> enter, which triggers a find-file on that image, it blanks the line, then loads the image.

Are you sure it blanks the line _before_ loading the image?  Could it
be that it blanks the line because it needs to display the image in
its stead?

And how is the cursor drawing involved in this?

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sat, Nov 03, 2018 at 10:57:14AM -0700, Aaron Jensen wrote:
> On November 1, 2018 at 3:55:23 PM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> 
> > I’ve done some digging, and I’m pretty tired right now so apologies if
> > this makes no sense, but it looks as though when Emacs is clearing the
> > cursor it redraws the entire line that contains the cursor.
> 
> Alan, would it help if you had access to my emacs config? Maybe then
> you could reproduce the exact thing on your machine?

We could certainly give it a go.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sat, Nov 03, 2018 at 11:31:07AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 1 Nov 2018 22:55:19 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Aaron Jensen <aaronjensen@gmail.com>, boris@d12frosted.io,
> > 	32932@debbugs.gnu.org
> > 
> > ns_get_glyph_string_clip_rect is a simple wrapper round
> > get_glyph_string_clip_rects, so when asked for the clipping rectangle
> > for a single glyph, it returns a rectangle covering the entire row.
> > 
> > Because we just mark it as dirty and come back to draw it later we do
> > end up redrawing the entire row.
> 
> I think if you are basing the redisplay on marking portions dirty, you
> need to include the same logic as in display_and_set_cursor and its
> callers.

What I don’t understand is how we’re getting a blanking of the line.
When redisplay runs it’s incapable of drawing to the screen, and even
if we mark too large an area as dirty it won’t draw anything at that
point.

Later drawRect runs which calls expose_frame on the area we’ve marked
as dirty. NOW it can draw to the screen, but for it to leave a line
blank it would have to actually call clear_frame or clear_frame_area,
then not call anything to draw over the blanked area.

Is it possible for expose_frame to stop drawing part‐way through?

Or perhaps expose_frame actually thinks it should be blank at that
moment, but for some reason we’ve not marked the whole window or
whatever as dirty?

So we’re to display an image but it’s not loaded yet, so redisplay
blanks the window for the time being, but we fail to mark it dirty or
garbaged. Expose_frame comes along and draws the bit we’ve previously
asked it to draw. Finally the image loads and redisplay marks the
whole window as dirty leading to everything catching up at the next
expose_frame.

-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sat, Nov 03, 2018 at 07:09:45PM +0000, Alan Third wrote:
> On Sat, Nov 03, 2018 at 10:57:14AM -0700, Aaron Jensen wrote:
> > On November 1, 2018 at 3:55:23 PM, Alan Third
> > (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> > 
> > > I’ve done some digging, and I’m pretty tired right now so apologies if
> > > this makes no sense, but it looks as though when Emacs is clearing the
> > > cursor it redraws the entire line that contains the cursor.
> > 
> > Alan, would it help if you had access to my emacs config? Maybe then
> > you could reproduce the exact thing on your machine?
> 
> We could certainly give it a go.

Actually, before that, can you try moving the call to
ns_reset_clipping back above draw_phys_cursor_glyph in
ns_draw_window_cursor?
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> Date: Sat, 3 Nov 2018 20:36:35 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: aaronjensen@gmail.com, boris@d12frosted.io, 32932@debbugs.gnu.org
> 
> > I think if you are basing the redisplay on marking portions dirty, you
> > need to include the same logic as in display_and_set_cursor and its
> > callers.
> 
> What I don’t understand is how we’re getting a blanking of the line.
> When redisplay runs it’s incapable of drawing to the screen, and even
> if we mark too large an area as dirty it won’t draw anything at that
> point.

What do you mean by "redisplay" in this context?  The function
redisplay_internal and the subroutines it calls?  If so, yes, that
doesn't draw anything, because AFAIU you've modified the functions
called from update_frame to mark portions of the frame dirty, but not
to redraw them.  (Other platforms do the redrawing inside update_frame
and update_window.)

> Later drawRect runs which calls expose_frame on the area we’ve marked
> as dirty. NOW it can draw to the screen, but for it to leave a line
> blank it would have to actually call clear_frame or clear_frame_area,
> then not call anything to draw over the blanked area.
> 
> Is it possible for expose_frame to stop drawing part‐way through?

No, I don't think so.  But what actually draws when expose_frame is
called is the backend-specific draw_glyph_string method, see
draw_glyphs.  What does the NS implementation of that method do when
it is handed a glyph string to draw? does it blank the entire line or
a part of it first?

> Or perhaps expose_frame actually thinks it should be blank at that
> moment, but for some reason we’ve not marked the whole window or
> whatever as dirty?
> 
> So we’re to display an image but it’s not loaded yet, so redisplay
> blanks the window for the time being, but we fail to mark it dirty or
> garbaged. Expose_frame comes along and draws the bit we’ve previously
> asked it to draw. Finally the image loads and redisplay marks the
> whole window as dirty leading to everything catching up at the next
> expose_frame.

I'm puzzled by this description, and actually by the whole larger
picture.  You see, I originally thought you had a problem of
flickering caused by redrawing the cursor, which was said to trigger
redrawing of the entire screen line where the cursor was, instead of
redrawing just the character under the cursor.  Is that still the
problem we are discussing?  If so, how does visiting the image file
come into play, and where is cursor positioned in this scenario?

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 3, 2018 at 1:51:24 PM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> On Sat, Nov 03, 2018 at 07:09:45PM +0000, Alan Third wrote:
> > > Alan, would it help if you had access to my emacs config? Maybe then
> > > you could reproduce the exact thing on your machine?
> >
> > We could certainly give it a go.
>
> Actually, before that, can you try moving the call to
> ns_reset_clipping back above draw_phys_cursor_glyph in
> ns_draw_window_cursor?

This did not help.

For my config, it turns out that spacemacs out of the box can reproduce this.

1. Back up your .emacs.d
2. git clone https://github.com/syl20bnr/spacemacs ~/.emacs.d
3. cd ~/.emacs.d
4. git checkout develop
5. emacs
6. Pick all the defaults for the setup (picking VIM is important, it
may be that evil is an important part of the repro for this)
7. Let it install packages, you may need to SPC q q then restart emacs
to let it finish
8. SPC f f
9. Navigate to a directory that has images in it and press enter
10. Use j/k to select an image in the dired and press enter

I’ve seen it blank from the cursor to the end of the line, from the
cursor to the beginning of the line and the entire line. I don’t know
how/why it does one or the other. It only does it once per image. If
you have several images in a single folder you could reproduce it
multiple times.

Hopefully that helps.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sat, Nov 03, 2018 at 11:03:27PM +0200, Eli Zaretskii wrote:
> > Or perhaps expose_frame actually thinks it should be blank at that
> > moment, but for some reason we’ve not marked the whole window or
> > whatever as dirty?
> > 
> > So we’re to display an image but it’s not loaded yet, so redisplay
> > blanks the window for the time being, but we fail to mark it dirty or
> > garbaged. Expose_frame comes along and draws the bit we’ve previously
> > asked it to draw. Finally the image loads and redisplay marks the
> > whole window as dirty leading to everything catching up at the next
> > expose_frame.
> 
> I'm puzzled by this description, and actually by the whole larger
> picture.  You see, I originally thought you had a problem of
> flickering caused by redrawing the cursor, which was said to trigger
> redrawing of the entire screen line where the cursor was, instead of
> redrawing just the character under the cursor.  Is that still the
> problem we are discussing?  If so, how does visiting the image file
> come into play, and where is cursor positioned in this scenario?

Apologies, Aaron’s repeatable test case involves a dired buffer of
images and hitting return on one of the images. There’s a pause while
it loads, during which the line with the cursor on it sometimes
blanks. Then the image loads.

I think what’s probably happening is that when the image begins to
load the emacs window containing the dired buffer is marked as
garbaged as it’s going to be replaced by the buffer containing the
image, however because there’s a reasonably long gap between the user
requesting the opening of the image, and the image actually loading
redisplay and expose_frame have time to run.

Because the window is marked as garbaged expose_window doesn’t do
anything.

This would be fine except we seem to have a rogue clear_area
somewhere. NSTrace doesn’t show it running, and they happen too often
for me to reasonably use a breakpoint to find it.

Here’s some output from NSTrace:

nsterm.m  : 4441: [53008]  ns_select
nsterm.m  : 5391: [53009]  | [EmacsApp run]
nsterm.m  : 5458: [53010]  | | [EmacsApp sendEvent:]
nsterm.m  : 5459: [53011]  | | +--- Type: 10

Here we have the user hitting return in the image file in dired.

nsterm.m  : 6076: [53012]  | | | [EmacsView keyDown:]
nsterm.m  : 4195: [53013]  | | | | ns_send_appdefined(-1)
nsterm.m  : 5458: [53014]  | | [EmacsApp sendEvent:]
nsterm.m  : 5459: [53015]  | | +--- Type: 15
nsterm.m  : 5429: [53016]  | | | [EmacsApp stop:]
nsterm.m  : 4359: [53017]  | ns_read_socket
nsterm.m  : 4359: [53018]  | ns_read_socket
nsterm.m  : 4195: [53019]  | | ns_send_appdefined(-1)
nsterm.m  : 5391: [53020]  | | [EmacsApp run]
nsterm.m  : 5458: [53021]  | | | [EmacsApp sendEvent:]
nsterm.m  : 5459: [53022]  | | | +--- Type: 15
nsterm.m  : 5429: [53023]  | | | | [EmacsApp stop:]
nsterm.m  : 4359: [53024]  | ns_read_socket
nsterm.m  : 4195: [53025]  | | ns_send_appdefined(-1)
nsterm.m  : 5391: [53026]  | | [EmacsApp run]
nsterm.m  : 5458: [53027]  | | | [EmacsApp sendEvent:]
nsterm.m  : 5459: [53028]  | | | +--- Type: 15
nsterm.m  : 5429: [53029]  | | | | [EmacsApp stop:]
nsterm.m  : 4359: [53030]  ns_read_socket
nsterm.m  : 4195: [53031]  | ns_send_appdefined(-1)
nsterm.m  : 5391: [53032]  | [EmacsApp run]
nsterm.m  : 5458: [53033]  | | [EmacsApp sendEvent:]
nsterm.m  : 5459: [53034]  | | +--- Type: 15
nsterm.m  : 5429: [53035]  | | | [EmacsApp stop:]

I believe this is now Emacs trying to modify the cursor. The cursor is
at pixel position (381, 268).

nsterm.m  : 2299: [53036]  ns_lisp_to_color
nsterm.m  : 2177: [53037]  | ns_get_color(LightGoldenrod3, **)
nsterm.m  : 4035: [53038]  ns_draw_glyph_string
nsterm.m  : 1191: [53039]  | ns_clip_to_rect
ns_clip_to_rect
nsterm.m  : 1195: [53040]  | +--- r: (X:10 Y:268)/(W:560 H:14)
nsterm.m  : 1214: [53041]  | +--- New dirty rect: (X:10 Y:268)/(W:560 H:14)
nsterm.m  : 3048: [53042]  ns_draw_window_cursor
nsterm.m  : 3048: [53043]  ns_draw_window_cursor
nsterm.m  : 3048: [53044]  ns_draw_window_cursor
nsterm.m  : 1191: [53045]  | ns_clip_to_rect
ns_clip_to_rect
nsterm.m  : 1195: [53046]  | +--- r: (X:381 Y:268)/(W:7 H:14)
nsterm.m  : 1214: [53047]  | +--- New dirty rect: (X:381 Y:268)/(W:7 H:14)
nsterm.m  : 3048: [53048]  ns_draw_window_cursor
nsimage.m :   61: [53049]  ns_image_for_XPM

I think these are functions called by redisplay_internal. I believe
they’re updating the modeline and/or the minibuffer.

nsterm.m  : 1060: [53050]  ns_update_begin
nsterm.m  : 1015: [53051]  | ns_update_auto_hide_menu_bar
nsterm.m  : 7772: [53052]  | [EmacsView isFullscreen] ->> 0
nsterm.m  : 1109: [53053]  ns_update_window_begin
nsterm.m  : 4035: [53054]  ns_draw_glyph_string
nsterm.m  : 1191: [53055]  | ns_clip_to_rect
ns_clip_to_rect
nsterm.m  : 1195: [53056]  | +--- r: (X:10 Y:492)/(W:560 H:14)
nsterm.m  : 1214: [53057]  | +--- New dirty rect: (X:10 Y:492)/(W:560 H:14)
nsterm.m  : 2682: [53058]  ns_clear_frame_area
nsterm.m  : 1191: [53059]  | ns_clip_to_rect
ns_clip_to_rect
nsterm.m  : 1195: [53060]  | +--- r: (X:416 Y:492)/(W:154 H:14)
nsterm.m  : 1214: [53061]  | +--- New dirty rect: (X:416 Y:492)/(W:154 H:14)
nsterm.m  : 1139: [53062]  ns_update_window_end
nsterm.m  : 3048: [53063]  | ns_draw_window_cursor
nsterm.m  : 1176: [53064]  ns_update_end
nsterm.m  : 2532: [53065]  ns_frame_up_to_date
nsterm.m  : 4359: [53066]  ns_read_socket
nsterm.m  : 4195: [53067]  | ns_send_appdefined(-1)
nsterm.m  : 5391: [53068]  | [EmacsApp run]

Now drawRect is called. It currently steps through each of the unique
dirty rectangles calling expose_frame.

nsterm.m  : 8100: [53069]  | | [EmacsView drawRect:(X:10 Y:268)/(W:560
H:238)]

modeline/minibuffer:

nsterm.m  : 8117: [53070]  | | +--- Exposing rect: (X:10 Y:492)/(W:560 H:14)
nsterm.m  : 3048: [53071]  | | | ns_draw_window_cursor
nsterm.m  : 4035: [53072]  | | | ns_draw_glyph_string
nsterm.m  : 1191: [53073]  | | | | ns_clip_to_rect
ns_clip_to_rect
nsterm.m  : 1195: [53074]  | | | | +--- r: (X:10 Y:492)/(W:560 H:14)
nsterm.m  : 3624: [53075]  | | | | ns_maybe_dumpglyphs_background
nsterm.m  : 1229: [53076]  | | | | ns_reset_clipping
nsterm.m  : 2922: [53077]  | | | ns_draw_fringe_bitmap
nsterm.m  : 2924: [53078]  | | | +--- which:0 cursor:0 overlay:0 width:0 height:0 period:0
nsterm.m  : 1191: [53079]  | | | | ns_clip_to_rect
ns_clip_to_rect
nsterm.m  : 1195: [53080]  | | | | +--- r: (X:2 Y:492)/(W:8 H:14)
nsterm.m  : 2961: [53081]  | | | +--- clearRect: (X:2 Y:492)/(W:8 H:14)
nsterm.m  : 1229: [53082]  | | | | ns_reset_clipping
nsterm.m  : 2922: [53083]  | | | ns_draw_fringe_bitmap
nsterm.m  : 2924: [53084]  | | | +--- which:0 cursor:0 overlay:0 width:0 height:0 period:0
nsterm.m  : 1191: [53085]  | | | | ns_clip_to_rect
ns_clip_to_rect
nsterm.m  : 1195: [53086]  | | | | +--- r: (X:570 Y:492)/(W:8 H:14)
nsterm.m  : 2961: [53087]  | | | +--- clearRect: (X:570 Y:492)/(W:8 H:14)
nsterm.m  : 1229: [53088]  | | | | ns_reset_clipping
nsterm.m  : 3048: [53089]  | | | ns_draw_window_cursor

Here it finally reaches the rectangle that contains the cursor. It
appears to do nothing. Not even clear the area.

nsterm.m  : 8117: [53090]  | | +--- Exposing rect: (X:10 Y:268)/(W:560 H:14)
nsterm.m  : 5458: [53091]  | | [EmacsApp sendEvent:]
nsterm.m  : 5459: [53092]  | | +--- Type: 11

I’ve tried to work out if drawRect is ‘helpfully’ clearing the dirty
rectangles for us, but I don’t think it is.

Perhaps this approach is just doomed to suffer from issues like these.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sat, Nov 03, 2018 at 04:56:42PM -0700, Aaron Jensen wrote:
> For my config, it turns out that spacemacs out of the box can reproduce this.
> 
> 1. Back up your .emacs.d
> 2. git clone https://github.com/syl20bnr/spacemacs ~/.emacs.d
> 3. cd ~/.emacs.d
> 4. git checkout develop
> 5. emacs
> 6. Pick all the defaults for the setup (picking VIM is important, it
> may be that evil is an important part of the repro for this)
> 7. Let it install packages, you may need to SPC q q then restart emacs
> to let it finish
> 8. SPC f f
> 9. Navigate to a directory that has images in it and press enter
> 10. Use j/k to select an image in the dired and press enter
> 
> I’ve seen it blank from the cursor to the end of the line, from the
> cursor to the beginning of the line and the entire line. I don’t know
> how/why it does one or the other. It only does it once per image. If
> you have several images in a single folder you could reproduce it
> multiple times.

Yes, I can reproduce with this. Thanks.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 4, 2018 at 5:24:58 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> Yes, I can reproduce with this. Thanks.

Oh, good.

I apologize if this is obvious or redundant, but have you tried
commenting out the erase_phys_cursor call in display_and_set_cursor?
For me, that makes the issue not happen (instead the cursor ghosts).

If I log x/y in the erase, after pressing enter I see this:

erasing 456 133
erasing 0 0
erasing 456 0
erasing 0 0
erasing 456 0
erasing 0 0

456, 133 is where the cursor is in dired. Is it strange that it’s
alternating between x coordinates?

Possibly related, after reproducing it, while writing this email, the
image I had open in the buffer flickered a couple of times. These were
in my log:

erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 456 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 480 19
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0
erasing 0 0


That 456 was there from a while ago which seems strange to me. What’s
holding on to that cursor’s coordinates?

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 4 Nov 2018 09:12:55 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>, 32932@debbugs.gnu.org, boris@d12frosted.io
> 
> If I log x/y in the erase, after pressing enter I see this:
> 
> erasing 456 133
> erasing 0 0
> erasing 456 0
> erasing 0 0
> erasing 456 0
> erasing 0 0
> 
> 456, 133 is where the cursor is in dired. Is it strange that it’s
> alternating between x coordinates?

Are these coordinates frame-relative or window-relative?  If the
latter, they could belong to more than one window.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sun, Nov 04, 2018 at 01:24:04PM +0000, Alan Third wrote:
> 
> I think what’s probably happening is that when the image begins to
> load the emacs window containing the dired buffer is marked as
> garbaged as it’s going to be replaced by the buffer containing the
> image, however because there’s a reasonably long gap between the user
> requesting the opening of the image, and the image actually loading
> redisplay and expose_frame have time to run.
> 
> Because the window is marked as garbaged expose_window doesn’t do
> anything.

After thinking about this for a while I realised that what we probably
need to do is just make sure the frame is updated before redisplay
starts changing it.

This seems to work here:

modified   src/nsterm.m
@@ -1061,6 +1061,17 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 
   ns_update_auto_hide_menu_bar ();
 
+  /* Flush any existing changes to screen before redisplay gets going.
+     If we don't do this then it's possible for redisplay to mark
+     areas as garbaged so they won't be redrawn in the next drawRect
+     call.
+
+     Is this a bad thing to do since we're effectively calling
+     frame_expose from within redisplay?  */
+  block_input ();
+  [FRAME_NS_VIEW (f) displayIfNeeded];
+  unblock_input ();
+
   if ([view isFullscreen] && [view fsIsNative])
   {
     // Fix reappearing tool bar in fullscreen for Mac OS X 10.7

-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 4, 2018 at 12:11:52 PM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> After thinking about this for a while I realised that what we probably
> need to do is just make sure the frame is updated before redisplay
> starts changing it.
>
> This seems to work here:
>
> modified src/nsterm.m
> @@ -1061,6 +1061,17 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
>
> ns_update_auto_hide_menu_bar ();
>
> + /* Flush any existing changes to screen before redisplay gets going.
> + If we don't do this then it's possible for redisplay to mark
> + areas as garbaged so they won't be redrawn in the next drawRect
> + call.
> +
> + Is this a bad thing to do since we're effectively calling
> + frame_expose from within redisplay? */
> + block_input ();
> + [FRAME_NS_VIEW (f) displayIfNeeded];
> + unblock_input ();
> +
> if ([view isFullscreen] && [view fsIsNative])
> {
> // Fix reappearing tool bar in fullscreen for Mac OS X 10.7


That works for me as well for my repro. I’ll try it out for a while
and report back if I notice any issues.

Thanks,

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

Answering below in case it’s still helpful.

On November 3, 2018 at 11:19:28 AM, Eli Zaretskii
(eliz@gnu.org(mailto:eliz@gnu.org)) wrote:

> > No, the problem is with the redrawing the cursor on the row that in the active window *before* the image
> > loads. See the attached gif. Frame 2 of the gif shows the blank. Frame 1 is before I press enter. When I press
> > enter, which triggers a find-file on that image, it blanks the line, then loads the image.
>
> Are you sure it blanks the line _before_ loading the image? Could it
> be that it blanks the line because it needs to display the image in
> its stead?

I’m not sure. Chronologically, it blanks it before loading the image.
What’s causing it to blank it, I cannot say, but perhaps Alan’s other
recent emails help with that.

> And how is the cursor drawing involved in this?

It’s always the line with the cursor that blanks. Sometimes it blanks
from the cursor to the end of the line. Sometimes from the start of
the line to the cursor and sometimes the entire line. That’s all I
know about the cursor’s involvement.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Mon, Nov 05, 2018 at 08:11:29AM -0800, Aaron Jensen wrote:
> On November 4, 2018 at 12:11:52 PM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> 
> > After thinking about this for a while I realised that what we probably
> > need to do is just make sure the frame is updated before redisplay
> > starts changing it.
> 
> That works for me as well for my repro. I’ll try it out for a while
> and report back if I notice any issues.

Believe it or not that works perfectly in spacemacs, but not in
standard emacs. The minibuffer flickers something awful when you type
in it.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 5, 2018 at 10:55:20 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> Believe it or not that works perfectly in spacemacs, but not in
> standard emacs. The minibuffer flickers something awful when you type
> in it.

I can reproduce that too…

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 5, 2018 at 8:04:35 PM, Aaron Jensen
(aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:

> On November 5, 2018 at 10:55:20 AM, Alan Third (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
>
> > Believe it or not that works perfectly in spacemacs, but not in
> > standard emacs. The minibuffer flickers something awful when you type
> > in it.
>
> I can reproduce that too…

FWIW, this patch also seems to cause partial paints when switching
buffers with something like a “goto definition” command. I end up
having to move the cursor around the entire buffer to get it to fill
in.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

I’ve finally worked out what’s happening.

We have an NSWindow, that is opaque, and drawn over that is the NSView
we use to display Emacs, which is not opaque.

When we ask for a display Cocoa/GNUstep back up to the first opaque
ancestor, in this case the NSWindow, and draws it, then moves up to
the NSView and draws it.

This means the first thing it does is draw the blank NSWindow
contents, which is why anything that is marked as dirty gets blanked
out.

Setting the NSView to be opaque solves the blanking issue, but
ns_clear_area and friends don’t do anything as they’re not called
during expose_frame.

We could work around that by queueing up the clear requests and
calling them in drawRect, however if the user set the background to be
transparent then I think we would immediately run into the exact same
issue as we have now where the first opaque ancestor (the WM root)
will overdraw when we’re not expecting it.

I think the root of this problem is that the NS toolkits expect
drawRect to ALWAYS be able to redraw the contents of the view at any
time so they have no issue with modifying it. Emacs seems to expect
the contents of the window to remain intact in many of these
circumstances.

We could try and force Emacs to bend to the NS way by forcing
expose_frame and friends to draw WHENEVER REQUESTED, but I don’t know
how practical that is, and it would mean making changes in xdisp.c
which may be unwelcome.

This leaves us with the solution Yamamoto Mitsuharu has used in the
Mac port of drawing to an offscreen buffer and leaving drawRect to
basically just copy that buffer to the screen.

It doesn’t feel like as neat a solution, but it should, more or less,
Just Work. Although I currently have no idea how to do it.

-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> Date: Thu, 8 Nov 2018 15:21:17 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 32932@debbugs.gnu.org,
> 	boris@d12frosted.io
> 
> We could try and force Emacs to bend to the NS way by forcing
> expose_frame and friends to draw WHENEVER REQUESTED, but I don’t know
> how practical that is, and it would mean making changes in xdisp.c
> which may be unwelcome.

What exactly do you mean by WHENEVER REQUESTED?  As opposed to what
alternative?

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Thu, Nov 08, 2018 at 05:35:53PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 8 Nov 2018 15:21:17 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 32932@debbugs.gnu.org,
> > 	boris@d12frosted.io
> > 
> > We could try and force Emacs to bend to the NS way by forcing
> > expose_frame and friends to draw WHENEVER REQUESTED, but I don’t know
> > how practical that is, and it would mean making changes in xdisp.c
> > which may be unwelcome.
> 
> What exactly do you mean by WHENEVER REQUESTED?  As opposed to what
> alternative?

At the moment expose_frame doesn’t draw anything if the frame or
window has been marked as garbaged (there may be other circumstances
too). Unfortunately this results in areas being cleared and not being
redrawn as Cocoa/GNUstep assume it is always possible to redraw
anything at any time.

It would be fine if there was a way to say to Cocoa/GNUstep to just
ignore that dirty rectangle for now, but there doesn’t seem to be, so
it clears the rectangle, asks expose_frame to draw it, but it doesn’t,
then marks the dirty rectangle as clean and continues.

If I could suppress the clearing action that would solve the problem.

If expose_frame could draw the rectangle as it was before the
frame/window was marked garbaged, that would also solve the problem.

I don’t believe the former is possible, and I don’t know if the latter
is possible.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 8, 2018 at 8:17:21 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> If I could suppress the clearing action that would solve the problem.
>
> If expose_frame could draw the rectangle as it was before the
> frame/window was marked garbaged, that would also solve the problem.
>
> I don’t believe the former is possible, and I don’t know if the latter
> is possible.

I’m only partially following this now, so I’m sorry if this idea
doesn’t make sense—but if there’s a spot where the repaint actually
happens, could you dirty the rects right before the repaint. In other
words, queue into a queue the rect dirtying in all the places it
happens and only actually process the dirty queue once you know you
can paint.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> Date: Thu, 8 Nov 2018 16:17:15 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: aaronjensen@gmail.com, 32932@debbugs.gnu.org, boris@d12frosted.io
> 
> > What exactly do you mean by WHENEVER REQUESTED?  As opposed to what
> > alternative?
> 
> At the moment expose_frame doesn’t draw anything if the frame or
> window has been marked as garbaged

AFAIR, that's a mere optimization, so if you want expose_frame to go
ahead and redraw on NS regardless of the frame's garbaged flag, it's
fine with me.

> (there may be other circumstances too).

The only other case is when the frame's face cache is empty, in which
case you won't be able to draw anything anyway.

There's a no-op return in expose_window, but I think its condition
cannot happen nowadays, it's a relic from when expose_frame could be
entered asynchronously from a signal handler.

> If expose_frame could draw the rectangle as it was before the
> frame/window was marked garbaged, that would also solve the problem.

Not sure what this means: you can only draw what's in the glyph
matrices, what was there before the garbaged flag was set is gone for
good.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1129 bytes --]

On Thu, Nov 08, 2018 at 08:28:03AM -0800, Aaron Jensen wrote:
> On November 8, 2018 at 8:17:21 AM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> 
> > If I could suppress the clearing action that would solve the problem.
> >
> > If expose_frame could draw the rectangle as it was before the
> > frame/window was marked garbaged, that would also solve the problem.
> >
> > I don’t believe the former is possible, and I don’t know if the latter
> > is possible.
> 
> I’m only partially following this now, so I’m sorry if this idea
> doesn’t make sense—but if there’s a spot where the repaint actually
> happens, could you dirty the rects right before the repaint. In other
> words, queue into a queue the rect dirtying in all the places it
> happens and only actually process the dirty queue once you know you
> can paint.

Yes, and I hadn’t thought of that option. It makes a lot more sense
than queueing the clears. I’ve got another patch for you to try first,
though. This one requires the previous one (i.e. you should be able to
just apply it without the removing anything).
-- 
Alan Third

[-- Attachment #2: 0001-Further-changes-to-NS-drawing-bug-32932.patch --]
[-- Type: text/plain, Size: 4221 bytes --]

From 171713fb172911416ac4615f4bf3ae1802a4e756 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Thu, 8 Nov 2018 23:11:31 +0000
Subject: [PATCH] Further changes to NS drawing (bug#32932)

* src/nsterm.m (ns_update_begin): Get rid of the display at the start
of redisplay.
(ns_update_window_begin): Remove redundant code that never executes.
(ns_draw_window_cursor): Perform a display when not in redisplay.
([EmacsView drawRect:]): Show the rectangle being exposed.
* src/xdisp.c (expose_window_tree) [HAVE_NS]:
(expose_frame) [HAVE_NS]: Redraw even if the frame is garbaged.
---
 src/nsterm.m | 43 +++++++++----------------------------------
 src/xdisp.c  |  8 +++++++-
 2 files changed, 16 insertions(+), 35 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index bb21be4a18..9e6779d4a3 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1061,17 +1061,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 
   ns_update_auto_hide_menu_bar ();
 
-  /* Flush any existing changes to screen before redisplay gets going.
-     If we don't do this then it's possible for redisplay to mark
-     areas as garbaged so they won't be redrawn in the next drawRect
-     call.
-
-     Is this a bad thing to do since we're effectively calling
-     frame_expose from within redisplay?  */
-  block_input ();
-  [FRAME_NS_VIEW (f) displayIfNeeded];
-  unblock_input ();
-
   if ([view isFullscreen] && [view fsIsNative])
   {
     // Fix reappearing tool bar in fullscreen for Mac OS X 10.7
@@ -1080,29 +1069,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
     if (! tbar_visible != ! [toolbar isVisible])
       [toolbar setVisible: tbar_visible];
   }
-
-  /* drawRect may have been called for say the minibuffer, and then clip path
-     is for the minibuffer.  But the display engine may draw more because
-     we have set the frame as garbaged.  So reset clip path to the whole
-     view.  */
-  /* FIXME: I don't think we need to do this.  */
-  if ([NSView focusView] == FRAME_NS_VIEW (f))
-    {
-      NSBezierPath *bp;
-      NSRect r = [view frame];
-      NSRect cr = [[view window] frame];
-      /* If a large frame size is set, r may be larger than the window frame
-         before constrained.  In that case don't change the clip path, as we
-         will clear in to the tool bar and title bar.  */
-      if (r.size.height
-          + FRAME_NS_TITLEBAR_HEIGHT (f)
-          + FRAME_TOOLBAR_HEIGHT (f) <= cr.size.height)
-        {
-          bp = [[NSBezierPath bezierPathWithRect: r] retain];
-          [bp setClip];
-          [bp release];
-        }
-    }
 #endif
 }
 
@@ -3158,6 +3124,12 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
 
       ns_reset_clipping (f);
     }
+  else if (! redisplaying_p)
+    {
+      /* If this function is called outside redisplay, it probably
+         means we need an immediate update.  */
+      [FRAME_NS_VIEW (f) display];
+    }
 }
 
 
@@ -8120,6 +8092,9 @@ - (void)drawRect: (NSRect)rect
   for (int i = 0 ; i < numRects ; i++)
     {
       NSRect r = rectList[i];
+
+      NSTRACE_RECT ("r", r);
+
       expose_frame (emacsframe,
                     NSMinX (r), NSMinY (r),
                     NSWidth (r), NSHeight (r));
diff --git a/src/xdisp.c b/src/xdisp.c
index 357f0fb30c..a59a62fb93 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -32258,7 +32258,11 @@ expose_window_tree (struct window *w, XRectangle *r)
   struct frame *f = XFRAME (w->frame);
   bool mouse_face_overwritten_p = false;
 
-  while (w && !FRAME_GARBAGED_P (f))
+  while (w
+#if !defined (HAVE_NS)
+         && !FRAME_GARBAGED_P (f)
+#endif
+         )
     {
       mouse_face_overwritten_p
 	|= (WINDOWP (w->contents)
@@ -32286,12 +32290,14 @@ expose_frame (struct frame *f, int x, int y, int w, int h)
 
   TRACE ((stderr, "expose_frame "));
 
+#if !defined (HAVE_NS)
   /* No need to redraw if frame will be redrawn soon.  */
   if (FRAME_GARBAGED_P (f))
     {
       TRACE ((stderr, " garbaged\n"));
       return;
     }
+#endif
 
   /* If basic faces haven't been realized yet, there is no point in
      trying to redraw anything.  This can happen when we get an expose
-- 
2.19.1

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Thu, Nov 08, 2018 at 06:51:37PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 8 Nov 2018 16:17:15 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: aaronjensen@gmail.com, 32932@debbugs.gnu.org, boris@d12frosted.io
> > 
> > > What exactly do you mean by WHENEVER REQUESTED?  As opposed to what
> > > alternative?
> > 
> > At the moment expose_frame doesn’t draw anything if the frame or
> > window has been marked as garbaged
> 
> AFAIR, that's a mere optimization, so if you want expose_frame to go
> ahead and redraw on NS regardless of the frame's garbaged flag, it's
> fine with me.
> 
> > (there may be other circumstances too).
> 
> The only other case is when the frame's face cache is empty, in which
> case you won't be able to draw anything anyway.
> 
> There's a no-op return in expose_window, but I think its condition
> cannot happen nowadays, it's a relic from when expose_frame could be
> entered asynchronously from a signal handler.

It may be worth keeping it for now as I’m unsure what will happen
when I finally get round to splitting the NS and lisp code into
separate threads (I had a go at it before and it was largely
successful, but there were a lot of graphical issues that caused
crashes).

> > If expose_frame could draw the rectangle as it was before the
> > frame/window was marked garbaged, that would also solve the problem.
> 
> Not sure what this means: you can only draw what's in the glyph
> matrices, what was there before the garbaged flag was set is gone for
> good.

That’s exactly what I meant. Thanks.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On November 8, 2018 at 3:21:19 PM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> Yes, and I hadn’t thought of that option. It makes a lot more sense
> than queueing the clears. I’ve got another patch for you to try first,
> though. This one requires the previous one (i.e. you should be able to
> just apply it without the removing anything).

I haven’t been able to apply that patch to any combination of
emacs-26/master and the previous two patches (or just the first patch)
that you’ve sent, would it be possible to send a complete patch from a
clean emacs-26 or master? I’m working off master, but I think you’re
working off emacs-26. So far the patches have applied to master as
well, which is what I use as my daily driver, so it’s better for me to
test with.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> Date: Thu, 8 Nov 2018 23:21:13 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 32932@debbugs.gnu.org,
> 	boris@d12frosted.io
> 
> I’ve got another patch for you to try first, though. This one
> requires the previous one (i.e. you should be able to just apply it
> without the removing anything).

If this is eventually installed, please add comments to explain why we
disregard the garbaged flag for NS.

Thanks.

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Alan Third]

* src/nsterm.m (ns_row_rect): New function.
(ns_clip_to_row): Remove function.
(ns_copy_bits): Fix mistake.
(ns_draw_fringe_bitmap): Stop using ns_clip_to_row.
(ns_draw_window_cursor): Stop using ns_clip_to_row and perform a
display when not in redisplay.
(ns_update_window_begin): Remove redundant code that never executes.
([EmacsView drawRect:]): Show the rectangle being exposed in NSTRACE.
* src/xdisp.c (expose_window_tree) [HAVE_NS]:
(expose_frame) [HAVE_NS]: Redraw even if the frame is garbaged.
---
I realised about 4AM that I'd screwed this up. This one should replace the
previous patch. Sorry for the hassle.

src/nsterm.m | 137 +++++++++++++++++++++++++--------------------------
 src/xdisp.c  |   8 ++-
 2 files changed, 75 insertions(+), 70 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 4b5d025ee3..9e6779d4a3 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -796,6 +796,27 @@ Free a pool and temporary objects it refers to (callable from C)
 }
 
 
+static NSRect
+ns_row_rect (struct window *w, struct glyph_row *row,
+               enum glyph_row_area area)
+/* Get the row as an NSRect.  */
+{
+  struct frame *f = XFRAME (WINDOW_FRAME (w));
+  NSRect rect;
+  int window_x, window_y, window_width;
+
+  window_box (w, area, &window_x, &window_y, &window_width, 0);
+
+  rect.origin.x = window_x;
+  rect.origin.y = WINDOW_TO_FRAME_PIXEL_Y (w, max (0, row->y));
+  rect.origin.y = max (rect.origin.y, window_y);
+  rect.size.width = window_width;
+  rect.size.height = row->visible_height;
+
+  return rect;
+}
+
+
 /* ==========================================================================
 
     Focus (clipping) and screen update
@@ -1048,29 +1069,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
     if (! tbar_visible != ! [toolbar isVisible])
       [toolbar setVisible: tbar_visible];
   }
-
-  /* drawRect may have been called for say the minibuffer, and then clip path
-     is for the minibuffer.  But the display engine may draw more because
-     we have set the frame as garbaged.  So reset clip path to the whole
-     view.  */
-  /* FIXME: I don't think we need to do this.  */
-  if ([NSView focusView] == FRAME_NS_VIEW (f))
-    {
-      NSBezierPath *bp;
-      NSRect r = [view frame];
-      NSRect cr = [[view window] frame];
-      /* If a large frame size is set, r may be larger than the window frame
-         before constrained.  In that case don't change the clip path, as we
-         will clear in to the tool bar and title bar.  */
-      if (r.size.height
-          + FRAME_NS_TITLEBAR_HEIGHT (f)
-          + FRAME_TOOLBAR_HEIGHT (f) <= cr.size.height)
-        {
-          bp = [[NSBezierPath bezierPathWithRect: r] retain];
-          [bp setClip];
-          [bp release];
-        }
-    }
 #endif
 }
 
@@ -1206,28 +1204,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 }
 
 
-static BOOL
-ns_clip_to_row (struct window *w, struct glyph_row *row,
-		enum glyph_row_area area, BOOL gc)
-/* --------------------------------------------------------------------------
-     Internal (but parallels other terms): Focus drawing on given row
-   -------------------------------------------------------------------------- */
-{
-  struct frame *f = XFRAME (WINDOW_FRAME (w));
-  NSRect clip_rect;
-  int window_x, window_y, window_width;
-
-  window_box (w, area, &window_x, &window_y, &window_width, 0);
-
-  clip_rect.origin.x = window_x;
-  clip_rect.origin.y = WINDOW_TO_FRAME_PIXEL_Y (w, max (0, row->y));
-  clip_rect.origin.y = max (clip_rect.origin.y, window_y);
-  clip_rect.size.width = window_width;
-  clip_rect.size.height = row->visible_height;
-
-  return ns_clip_to_rect (f, &clip_rect, 1);
-}
-
 /* ==========================================================================
 
     Visible bell and beep.
@@ -2692,7 +2668,7 @@ so some key presses (TAB) are swallowed by the system. */
 ns_copy_bits (struct frame *f, NSRect src, NSRect dest)
 {
   NSSize delta = NSMakeSize (dest.origin.x - src.origin.x,
-                             dest.origin.y - src.origin.y)
+                             dest.origin.y - src.origin.y);
   NSTRACE ("ns_copy_bits");
 
   if (FRAME_NS_VIEW (f))
@@ -2911,6 +2887,9 @@ so some key presses (TAB) are swallowed by the system. */
   struct face *face = p->face;
   static EmacsImage **bimgs = NULL;
   static int nBimgs = 0;
+  NSRect clearRect = NSZeroRect;
+  NSRect imageRect = NSZeroRect;
+  NSRect rowRect = ns_row_rect (w, row, ANY_AREA);
 
   NSTRACE_WHEN (NSTRACE_GROUP_FRINGE, "ns_draw_fringe_bitmap");
   NSTRACE_MSG ("which:%d cursor:%d overlay:%d width:%d height:%d period:%d",
@@ -2925,25 +2904,40 @@ so some key presses (TAB) are swallowed by the system. */
       nBimgs = max_used_fringe_bitmap;
     }
 
-  /* Must clip because of partially visible lines.  */
-  if (ns_clip_to_row (w, row, ANY_AREA, YES))
+  /* Work out the rectangle we will composite into.  */
+  if (p->which)
+    imageRect = NSMakeRect (p->x, p->y, p->wd, p->h);
+
+  /* Work out the rectangle we will need to clear.  Because we're
+     compositing rather than blitting, we need to clear the area under
+     the image regardless of anything else.  */
+  if (!p->overlay_p)
     {
-      if (!p->overlay_p)
+      clearRect = NSMakeRect (p->bx, p->by, p->nx, p->ny);
+      clearRect = NSUnionRect (clearRect, imageRect);
+    }
+  else
+    {
+      clearRect = imageRect;
+    }
+
+  /* Handle partially visible rows.  */
+  clearRect = NSIntersectionRect (clearRect, rowRect);
+
+  /* The visible portion of imageRect will always be contained within
+     clearRect.  */
+  if (ns_clip_to_rect (f, &clearRect, 1))
+    {
+      if (! NSIsEmptyRect (clearRect))
         {
-          int bx = p->bx, by = p->by, nx = p->nx, ny = p->ny;
+          NSTRACE_RECT ("clearRect", clearRect);
 
-          if (bx >= 0 && nx > 0)
-            {
-              NSRect r = NSMakeRect (bx, by, nx, ny);
-              NSRectClip (r);
-              [ns_lookup_indexed_color (face->background, f) set];
-              NSRectFill (r);
-            }
+          [ns_lookup_indexed_color(face->background, f) set];
+          NSRectFill (clearRect);
         }
 
       if (p->which)
         {
-          NSRect r = NSMakeRect (p->x, p->y, p->wd, p->h);
           EmacsImage *img = bimgs[p->which - 1];
 
           if (!img)
@@ -2964,13 +2958,6 @@ so some key presses (TAB) are swallowed by the system. */
               xfree (cbits);
             }
 
-          NSTRACE_RECT ("r", r);
-
-          NSRectClip (r);
-          /* Since we composite the bitmap instead of just blitting it, we need
-             to erase the whole background.  */
-          [ns_lookup_indexed_color(face->background, f) set];
-          NSRectFill (r);
 
           {
             NSColor *bm_color;
@@ -2990,7 +2977,7 @@ so some key presses (TAB) are swallowed by the system. */
 
           NSTRACE_RECT ("fromRect", fromRect);
 
-          [img drawInRect: r
+          [img drawInRect: imageRect
                  fromRect: fromRect
                 operation: NSCompositingOperationSourceOver
                  fraction: 1.0
@@ -2998,7 +2985,7 @@ so some key presses (TAB) are swallowed by the system. */
                     hints: nil];
 #else
           {
-            NSPoint pt = r.origin;
+            NSPoint pt = imageRect.origin;
             pt.y += p->h;
             [img compositeToPoint: pt operation: NSCompositingOperationSourceOver];
           }
@@ -3088,7 +3075,9 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
   r.size.width = w->phys_cursor_width;
 
   /* Prevent the cursor from being drawn outside the text area.  */
-  if (ns_clip_to_row (w, glyph_row, TEXT_AREA, NO))
+  r = NSIntersectionRect (r, ns_row_rect (w, glyph_row, TEXT_AREA));
+
+  if (ns_clip_to_rect (f, &r, 1))
     {
       face = FACE_FROM_ID_OR_NULL (f, phys_cursor_glyph->face_id);
       if (face && NS_FACE_BACKGROUND (face)
@@ -3128,11 +3117,18 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
           NSRectFill (s);
           break;
         }
-      ns_reset_clipping (f);
 
       /* draw the character under the cursor */
       if (cursor_type != NO_CURSOR)
         draw_phys_cursor_glyph (w, glyph_row, DRAW_CURSOR);
+
+      ns_reset_clipping (f);
+    }
+  else if (! redisplaying_p)
+    {
+      /* If this function is called outside redisplay, it probably
+         means we need an immediate update.  */
+      [FRAME_NS_VIEW (f) display];
     }
 }
 
@@ -8096,6 +8092,9 @@ - (void)drawRect: (NSRect)rect
   for (int i = 0 ; i < numRects ; i++)
     {
       NSRect r = rectList[i];
+
+      NSTRACE_RECT ("r", r);
+
       expose_frame (emacsframe,
                     NSMinX (r), NSMinY (r),
                     NSWidth (r), NSHeight (r));
diff --git a/src/xdisp.c b/src/xdisp.c
index 357f0fb30c..a59a62fb93 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -32258,7 +32258,11 @@ expose_window_tree (struct window *w, XRectangle *r)
   struct frame *f = XFRAME (w->frame);
   bool mouse_face_overwritten_p = false;
 
-  while (w && !FRAME_GARBAGED_P (f))
+  while (w
+#if !defined (HAVE_NS)
+         && !FRAME_GARBAGED_P (f)
+#endif
+         )
     {
       mouse_face_overwritten_p
 	|= (WINDOWP (w->contents)
@@ -32286,12 +32290,14 @@ expose_frame (struct frame *f, int x, int y, int w, int h)
 
   TRACE ((stderr, "expose_frame "));
 
+#if !defined (HAVE_NS)
   /* No need to redraw if frame will be redrawn soon.  */
   if (FRAME_GARBAGED_P (f))
     {
       TRACE ((stderr, " garbaged\n"));
       return;
     }
+#endif
 
   /* If basic faces haven't been realized yet, there is no point in
      trying to redraw anything.  This can happen when we get an expose
-- 
2.19.1


-- 
Alan Third

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Aaron Jensen]

On November 9, 2018 at 1:09:00 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> * src/nsterm.m (ns_row_rect): New function.
> (ns_clip_to_row): Remove function.
> (ns_copy_bits): Fix mistake.
> (ns_draw_fringe_bitmap): Stop using ns_clip_to_row.
> (ns_draw_window_cursor): Stop using ns_clip_to_row and perform a
> display when not in redisplay.
> (ns_update_window_begin): Remove redundant code that never executes.
> ([EmacsView drawRect:]): Show the rectangle being exposed in NSTRACE.
> * src/xdisp.c (expose_window_tree) [HAVE_NS]:
> (expose_frame) [HAVE_NS]: Redraw even if the frame is garbaged.
> ---
> I realised about 4AM that I'd screwed this up. This one should replace the
> previous patch. Sorry for the hassle.

Thanks, this applied. I can’t reproduce the issue w/ my repro. I’ll
try it out for a bit and report back.

Cheers,

Aaron

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Aaron Jensen]

On November 9, 2018 at 5:45:34 AM, Aaron Jensen
(aaronjensen@gmail.com(mailto:aaronjensen@gmail.com)) wrote:

> On November 9, 2018 at 1:09:00 AM, Alan Third (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
>
> > * src/nsterm.m (ns_row_rect): New function.
> > (ns_clip_to_row): Remove function.
> > (ns_copy_bits): Fix mistake.
> > (ns_draw_fringe_bitmap): Stop using ns_clip_to_row.
> > (ns_draw_window_cursor): Stop using ns_clip_to_row and perform a
> > display when not in redisplay.
> > (ns_update_window_begin): Remove redundant code that never executes.
> > ([EmacsView drawRect:]): Show the rectangle being exposed in NSTRACE.
> > * src/xdisp.c (expose_window_tree) [HAVE_NS]:
> > (expose_frame) [HAVE_NS]: Redraw even if the frame is garbaged.
> > ---
> > I realised about 4AM that I'd screwed this up. This one should replace the
> > previous patch. Sorry for the hassle.
>
> Thanks, this applied. I can’t reproduce the issue w/ my repro. I’ll try it out for a bit and report back.

I’ve twice seen a full frame blank. The first time was when pasting
something using cmd+v (it only happened the once) and the second time,
I don’t recall what I was doing. The first time it repainted the
entire frame with its two windows fine. The second time it repainted
the cursor on the inactive window and a seemingly random rectangle on
the active window that spanned several lines down below the cursor and
half the window’s width to the right.

I’ll keep using it and see if I can come up with any repros.

Aaron

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

On Fri, Nov 09, 2018 at 06:15:24AM -0800, Aaron Jensen wrote:
> 
> I’ve twice seen a full frame blank. The first time was when pasting
> something using cmd+v (it only happened the once) and the second time,
> I don’t recall what I was doing. The first time it repainted the
> entire frame with its two windows fine. The second time it repainted
> the cursor on the inactive window and a seemingly random rectangle on
> the active window that spanned several lines down below the cursor and
> half the window’s width to the right.

OK, so all new patch. It should apply to emacs-26 without any
additional patches (and might be OK for master too). Just the usual
’git am’ should apply all four, I believe.

If you can ignore the outer border randomly drawing in the wrong
colour, images being upside down and live‐resize displaying the frame
in black, then you’ll probably get along pretty well with this.

(There’s also a slightly odd redrawing issue with the title and tool
bars when dragging between monitors. No idea why that’s happening.)

Additionally, the fonts are drawn differently. I imagine that’s the
lack of subpixel anti‐aliasing that Yamamoto Mitsuharu talks about in
the Mac port release notes, in which case you won’t notice anything on
10.14.
-- 
Alan Third

[-- Attachment #2: draw-to-buffer.mbox --]
[-- Type: text/plain, Size: 50257 bytes --]

From b62bf4e329b106c08311456059f464ab44092a7f Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Mon, 12 Nov 2018 11:28:27 +0000
Subject: [PATCH 1/4] Revert "Fix some NS drawing issues (bug#32932)"

This reverts commit 7e8eee60a9dbb0c59cf26f237b21efe7fd1043c9.
---
 src/nsterm.m | 80 ++++++++++++++++++++++++++++------------------------
 1 file changed, 43 insertions(+), 37 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 4b5d025ee3..8c355a89f8 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -277,6 +277,7 @@ - (NSColor *)colorUsingDefaultColorSpace
 
 /* display update */
 static int ns_window_num = 0;
+static BOOL gsaved = NO;
 static BOOL ns_fake_keydown = NO;
 #ifdef NS_IMPL_COCOA
 static BOOL ns_menu_bar_is_hidden = NO;
@@ -1179,6 +1180,7 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
             NSRectClipList (r, 2);
           else
             NSRectClip (*r);
+          gsaved = YES;
 
           return YES;
         }
@@ -1202,7 +1204,11 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 {
   NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "ns_reset_clipping");
 
-  [[NSGraphicsContext currentContext] restoreGraphicsState];
+  if (gsaved)
+    {
+      [[NSGraphicsContext currentContext] restoreGraphicsState];
+      gsaved = NO;
+    }
 }
 
 
@@ -1228,6 +1234,19 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
   return ns_clip_to_rect (f, &clip_rect, 1);
 }
 
+
+static void
+ns_flush_display (struct frame *f)
+/* Force the frame to redisplay.  If areas have previously been marked
+   dirty by setNeedsDisplayInRect (in ns_clip_to_rect), then this will call
+   draw_rect: which will "expose" those areas.  */
+{
+  block_input ();
+  [FRAME_NS_VIEW (f) displayIfNeeded];
+  unblock_input ();
+}
+
+
 /* ==========================================================================
 
     Visible bell and beep.
@@ -2691,8 +2710,6 @@ so some key presses (TAB) are swallowed by the system. */
 static void
 ns_copy_bits (struct frame *f, NSRect src, NSRect dest)
 {
-  NSSize delta = NSMakeSize (dest.origin.x - src.origin.x,
-                             dest.origin.y - src.origin.y)
   NSTRACE ("ns_copy_bits");
 
   if (FRAME_NS_VIEW (f))
@@ -2701,21 +2718,10 @@ so some key presses (TAB) are swallowed by the system. */
 
       /* FIXME: scrollRect:by: is deprecated in macOS 10.14.  There is
          no obvious replacement so we may have to come up with our own.  */
-      [FRAME_NS_VIEW (f) scrollRect: src by: delta];
-
-#ifdef NS_IMPL_COCOA
-      /* As far as I can tell from the documentation, scrollRect:by:,
-         above, should copy the dirty rectangles from our source
-         rectangle to our destination, however it appears it clips the
-         operation to src.  As a result we need to use
-         translateRectsNeedingDisplayInRect:by: below, and we have to
-         union src and dest so it can pick up the dirty rectangles,
-         and place them, as it also clips to the rectangle.
-
-         FIXME: We need a GNUstep equivalent.  */
-      [FRAME_NS_VIEW (f) translateRectsNeedingDisplayInRect:NSUnionRect (src, dest)
-                                                         by:delta];
-#endif
+      [FRAME_NS_VIEW (f) scrollRect: src
+                                 by: NSMakeSize (dest.origin.x - src.origin.x,
+                                                 dest.origin.y - src.origin.y)];
+      [FRAME_NS_VIEW (f) setNeedsDisplay:YES];
     }
 }
 
@@ -3100,6 +3106,15 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
       else
         [FRAME_CURSOR_COLOR (f) set];
 
+#ifdef NS_IMPL_COCOA
+      /* TODO: This makes drawing of cursor plus that of phys_cursor_glyph
+         atomic.  Cleaner ways of doing this should be investigated.
+         One way would be to set a global variable DRAWING_CURSOR
+         when making the call to draw_phys..(), don't focus in that
+         case, then move the ns_reset_clipping() here after that call.  */
+      NSDisableScreenUpdates ();
+#endif
+
       switch (cursor_type)
         {
         case DEFAULT_CURSOR:
@@ -3133,6 +3148,10 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
       /* draw the character under the cursor */
       if (cursor_type != NO_CURSOR)
         draw_phys_cursor_glyph (w, glyph_row, DRAW_CURSOR);
+
+#ifdef NS_IMPL_COCOA
+      NSEnableScreenUpdates ();
+#endif
     }
 }
 
@@ -4958,7 +4977,7 @@ static Lisp_Object ns_string_to_lispmod (const char *s)
   ns_after_update_window_line,
   ns_update_window_begin,
   ns_update_window_end,
-  0, /* flush_display */
+  ns_flush_display, /* flush_display */
   x_clear_window_mouse_face,
   x_get_glyph_overhangs,
   x_fix_overlapping_area,
@@ -7027,6 +7046,7 @@ - (NSSize)windowWillResize: (NSWindow *)sender toSize: (NSSize)frameSize
         size_title = xmalloc (strlen (old_title) + 40);
 	esprintf (size_title, "%s  —  (%d x %d)", old_title, cols, rows);
         [window setTitle: [NSString stringWithUTF8String: size_title]];
+        [window display];
         xfree (size_title);
       }
   }
@@ -8075,8 +8095,8 @@ - (instancetype)toggleToolbar: (id)sender
 
 - (void)drawRect: (NSRect)rect
 {
-  const NSRect *rectList;
-  NSInteger numRects;
+  int x = NSMinX (rect), y = NSMinY (rect);
+  int width = NSWidth (rect), height = NSHeight (rect);
 
   NSTRACE ("[EmacsView drawRect:" NSTRACE_FMT_RECT "]",
            NSTRACE_ARG_RECT(rect));
@@ -8084,23 +8104,9 @@ - (void)drawRect: (NSRect)rect
   if (!emacsframe || !emacsframe->output_data.ns)
     return;
 
+  ns_clear_frame_area (emacsframe, x, y, width, height);
   block_input ();
-
-  /* Get only the precise dirty rectangles to avoid redrawing
-     potentially large areas of the frame that haven't changed.
-
-     I'm not sure this actually provides much of a performance benefit
-     as it's hard to benchmark, but it certainly doesn't seem to
-     hurt.  */
-  [self getRectsBeingDrawn:&rectList count:&numRects];
-  for (int i = 0 ; i < numRects ; i++)
-    {
-      NSRect r = rectList[i];
-      expose_frame (emacsframe,
-                    NSMinX (r), NSMinY (r),
-                    NSWidth (r), NSHeight (r));
-    }
-
+  expose_frame (emacsframe, x, y, width, height);
   unblock_input ();
 
   /*
-- 
2.19.1


From 1b3d42a83b79a27c29be475dabc1d6be5b91383b Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Mon, 12 Nov 2018 11:28:48 +0000
Subject: [PATCH 2/4] Revert "Ensure NS frame is redrawn correctly  after
 scroll"

This reverts commit a6ab8db3a3dc5ec107ef023c6659620584309c97.
---
 src/nsterm.m | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 8c355a89f8..d92d6c3244 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2721,7 +2721,6 @@ so some key presses (TAB) are swallowed by the system. */
       [FRAME_NS_VIEW (f) scrollRect: src
                                  by: NSMakeSize (dest.origin.x - src.origin.x,
                                                  dest.origin.y - src.origin.y)];
-      [FRAME_NS_VIEW (f) setNeedsDisplay:YES];
     }
 }
 
-- 
2.19.1


From e63c4e1bc305be13ff9b308019cb9d78cda697fc Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Mon, 12 Nov 2018 11:29:07 +0000
Subject: [PATCH 3/4] Revert "Make all NS drawing be done from drawRect"

This reverts commit 7946445962372c4255180af45cb7c857f1b0b5fa.
---
 src/nsterm.m | 767 ++++++++++++++++++++++++++-------------------------
 1 file changed, 391 insertions(+), 376 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index d92d6c3244..abb80c9938 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -276,7 +276,12 @@ - (NSColor *)colorUsingDefaultColorSpace
 long context_menu_value = 0;
 
 /* display update */
+static struct frame *ns_updating_frame;
+static NSView *focus_view = NULL;
 static int ns_window_num = 0;
+#ifdef NS_IMPL_GNUSTEP
+static NSRect uRect;            // TODO: This is dead, remove it?
+#endif
 static BOOL gsaved = NO;
 static BOOL ns_fake_keydown = NO;
 #ifdef NS_IMPL_COCOA
@@ -1034,13 +1039,12 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
    external (RIF) call; whole frame, called before update_window_begin
    -------------------------------------------------------------------------- */
 {
-#ifdef NS_IMPL_COCOA
   EmacsView *view = FRAME_NS_VIEW (f);
-
   NSTRACE_WHEN (NSTRACE_GROUP_UPDATES, "ns_update_begin");
 
   ns_update_auto_hide_menu_bar ();
 
+#ifdef NS_IMPL_COCOA
   if ([view isFullscreen] && [view fsIsNative])
   {
     // Fix reappearing tool bar in fullscreen for Mac OS X 10.7
@@ -1049,29 +1053,36 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
     if (! tbar_visible != ! [toolbar isVisible])
       [toolbar setVisible: tbar_visible];
   }
+#endif
+
+  ns_updating_frame = f;
+  [view lockFocus];
 
   /* drawRect may have been called for say the minibuffer, and then clip path
      is for the minibuffer.  But the display engine may draw more because
      we have set the frame as garbaged.  So reset clip path to the whole
      view.  */
-  /* FIXME: I don't think we need to do this.  */
-  if ([NSView focusView] == FRAME_NS_VIEW (f))
-    {
-      NSBezierPath *bp;
-      NSRect r = [view frame];
-      NSRect cr = [[view window] frame];
-      /* If a large frame size is set, r may be larger than the window frame
-         before constrained.  In that case don't change the clip path, as we
-         will clear in to the tool bar and title bar.  */
-      if (r.size.height
-          + FRAME_NS_TITLEBAR_HEIGHT (f)
-          + FRAME_TOOLBAR_HEIGHT (f) <= cr.size.height)
-        {
-          bp = [[NSBezierPath bezierPathWithRect: r] retain];
-          [bp setClip];
-          [bp release];
-        }
-    }
+#ifdef NS_IMPL_COCOA
+  {
+    NSBezierPath *bp;
+    NSRect r = [view frame];
+    NSRect cr = [[view window] frame];
+    /* If a large frame size is set, r may be larger than the window frame
+       before constrained.  In that case don't change the clip path, as we
+       will clear in to the tool bar and title bar.  */
+    if (r.size.height
+        + FRAME_NS_TITLEBAR_HEIGHT (f)
+        + FRAME_TOOLBAR_HEIGHT (f) <= cr.size.height)
+      {
+        bp = [[NSBezierPath bezierPathWithRect: r] retain];
+        [bp setClip];
+        [bp release];
+      }
+  }
+#endif
+
+#ifdef NS_IMPL_GNUSTEP
+  uRect = NSMakeRect (0, 0, 0, 0);
 #endif
 }
 
@@ -1153,66 +1164,99 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
    external (RIF) call; for whole frame, called after update_window_end
    -------------------------------------------------------------------------- */
 {
+  EmacsView *view = FRAME_NS_VIEW (f);
+
   NSTRACE_WHEN (NSTRACE_GROUP_UPDATES, "ns_update_end");
 
 /*   if (f == MOUSE_HL_INFO (f)->mouse_face_mouse_frame) */
   MOUSE_HL_INFO (f)->mouse_face_defer = 0;
-}
 
+  block_input ();
 
-static BOOL
-ns_clip_to_rect (struct frame *f, NSRect *r, int n)
+  [view unlockFocus];
+  [[view window] flushWindow];
+
+  unblock_input ();
+  ns_updating_frame = NULL;
+}
+
+static void
+ns_focus (struct frame *f, NSRect *r, int n)
 /* --------------------------------------------------------------------------
-   Clip the drawing area to rectangle r in frame f.  If drawing is not
-   currently possible mark r as dirty and return NO, otherwise return
-   YES.
+   Internal: Focus on given frame.  During small local updates this is used to
+     draw, however during large updates, ns_update_begin and ns_update_end are
+     called to wrap the whole thing, in which case these calls are stubbed out.
+     Except, on GNUstep, we accumulate the rectangle being drawn into, because
+     the back end won't do this automatically, and will just end up flushing
+     the entire window.
    -------------------------------------------------------------------------- */
 {
-  NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "ns_clip_to_rect");
-  if (r)
+  NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "ns_focus");
+  if (r != NULL)
     {
       NSTRACE_RECT ("r", *r);
+    }
 
-      if ([NSView focusView] == FRAME_NS_VIEW (f))
+  if (f != ns_updating_frame)
+    {
+      NSView *view = FRAME_NS_VIEW (f);
+      if (view != focus_view)
         {
-          [[NSGraphicsContext currentContext] saveGraphicsState];
-          if (n == 2)
-            NSRectClipList (r, 2);
-          else
-            NSRectClip (*r);
-          gsaved = YES;
+          if (focus_view != NULL)
+            {
+              [focus_view unlockFocus];
+              [[focus_view window] flushWindow];
+/*debug_lock--; */
+            }
 
-          return YES;
-        }
-      else
-        {
-          NSView *view = FRAME_NS_VIEW (f);
-          int i;
-          for (i = 0 ; i < n ; i++)
-            [view setNeedsDisplayInRect:r[i]];
+          if (view)
+            [view lockFocus];
+          focus_view = view;
+/*if (view) debug_lock++; */
         }
     }
 
-  return NO;
+  /* clipping */
+  if (r)
+    {
+      [[NSGraphicsContext currentContext] saveGraphicsState];
+      if (n == 2)
+        NSRectClipList (r, 2);
+      else
+        NSRectClip (*r);
+      gsaved = YES;
+    }
 }
 
 
 static void
-ns_reset_clipping (struct frame *f)
-/* Internal: Restore the previous graphics state, unsetting any
-   clipping areas.  */
+ns_unfocus (struct frame *f)
+/* --------------------------------------------------------------------------
+     Internal: Remove focus on given frame
+   -------------------------------------------------------------------------- */
 {
-  NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "ns_reset_clipping");
+  NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "ns_unfocus");
 
   if (gsaved)
     {
       [[NSGraphicsContext currentContext] restoreGraphicsState];
       gsaved = NO;
     }
+
+  if (f != ns_updating_frame)
+    {
+      if (focus_view != NULL)
+        {
+          [focus_view unlockFocus];
+          [[focus_view window] flushWindow];
+          focus_view = NULL;
+/*debug_lock--; */
+        }
+    }
 }
 
 
-static BOOL
+static void
 ns_clip_to_row (struct window *w, struct glyph_row *row,
 		enum glyph_row_area area, BOOL gc)
 /* --------------------------------------------------------------------------
@@ -1231,19 +1275,7 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
   clip_rect.size.width = window_width;
   clip_rect.size.height = row->visible_height;
 
-  return ns_clip_to_rect (f, &clip_rect, 1);
-}
-
-
-static void
-ns_flush_display (struct frame *f)
-/* Force the frame to redisplay.  If areas have previously been marked
-   dirty by setNeedsDisplayInRect (in ns_clip_to_rect), then this will call
-   draw_rect: which will "expose" those areas.  */
-{
-  block_input ();
-  [FRAME_NS_VIEW (f) displayIfNeeded];
-  unblock_input ();
+  ns_focus (f, &clip_rect, 1);
 }
 
 
@@ -2667,16 +2699,14 @@ so some key presses (TAB) are swallowed by the system. */
   r = [view bounds];
 
   block_input ();
-  if (ns_clip_to_rect (f, &r, 1))
-    {
-      [ns_lookup_indexed_color (NS_FACE_BACKGROUND
-                                (FACE_FROM_ID (f, DEFAULT_FACE_ID)), f) set];
-      NSRectFill (r);
-      ns_reset_clipping (f);
-
-      /* as of 2006/11 or so this is now needed */
-      ns_redraw_scroll_bars (f);
-    }
+  ns_focus (f, &r, 1);
+  [ns_lookup_indexed_color (NS_FACE_BACKGROUND
+			    (FACE_FROM_ID (f, DEFAULT_FACE_ID)), f) set];
+  NSRectFill (r);
+  ns_unfocus (f);
+
+  /* as of 2006/11 or so this is now needed */
+  ns_redraw_scroll_bars (f);
   unblock_input ();
 }
 
@@ -2697,14 +2727,13 @@ so some key presses (TAB) are swallowed by the system. */
   NSTRACE_WHEN (NSTRACE_GROUP_UPDATES, "ns_clear_frame_area");
 
   r = NSIntersectionRect (r, [view frame]);
-  if (ns_clip_to_rect (f, &r, 1))
-    {
-      [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
+  ns_focus (f, &r, 1);
+  [ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), f) set];
 
-      NSRectFill (r);
+  NSRectFill (r);
 
-      ns_reset_clipping (f);
-    }
+  ns_unfocus (f);
+  return;
 }
 
 static void
@@ -2716,11 +2745,11 @@ so some key presses (TAB) are swallowed by the system. */
     {
       hide_bell();              // Ensure the bell image isn't scrolled.
 
-      /* FIXME: scrollRect:by: is deprecated in macOS 10.14.  There is
-         no obvious replacement so we may have to come up with our own.  */
+      ns_focus (f, &dest, 1);
       [FRAME_NS_VIEW (f) scrollRect: src
                                  by: NSMakeSize (dest.origin.x - src.origin.x,
                                                  dest.origin.y - src.origin.y)];
+      ns_unfocus (f);
     }
 }
 
@@ -2931,86 +2960,85 @@ so some key presses (TAB) are swallowed by the system. */
     }
 
   /* Must clip because of partially visible lines.  */
-  if (ns_clip_to_row (w, row, ANY_AREA, YES))
+  ns_clip_to_row (w, row, ANY_AREA, YES);
+
+  if (!p->overlay_p)
     {
-      if (!p->overlay_p)
-        {
-          int bx = p->bx, by = p->by, nx = p->nx, ny = p->ny;
+      int bx = p->bx, by = p->by, nx = p->nx, ny = p->ny;
 
-          if (bx >= 0 && nx > 0)
-            {
-              NSRect r = NSMakeRect (bx, by, nx, ny);
-              NSRectClip (r);
-              [ns_lookup_indexed_color (face->background, f) set];
-              NSRectFill (r);
-            }
+      if (bx >= 0 && nx > 0)
+        {
+          NSRect r = NSMakeRect (bx, by, nx, ny);
+          NSRectClip (r);
+          [ns_lookup_indexed_color (face->background, f) set];
+          NSRectFill (r);
         }
+    }
 
-      if (p->which)
-        {
-          NSRect r = NSMakeRect (p->x, p->y, p->wd, p->h);
-          EmacsImage *img = bimgs[p->which - 1];
+  if (p->which)
+    {
+      NSRect r = NSMakeRect (p->x, p->y, p->wd, p->h);
+      EmacsImage *img = bimgs[p->which - 1];
 
-          if (!img)
-            {
-              // Note: For "periodic" images, allocate one EmacsImage for
-              // the base image, and use it for all dh:s.
-              unsigned short *bits = p->bits;
-              int full_height = p->h + p->dh;
-              int i;
-              unsigned char *cbits = xmalloc (full_height);
-
-              for (i = 0; i < full_height; i++)
-                cbits[i] = bits[i];
-              img = [[EmacsImage alloc] initFromXBM: cbits width: 8
-                                             height: full_height
-                                                 fg: 0 bg: 0];
-              bimgs[p->which - 1] = img;
-              xfree (cbits);
-            }
+      if (!img)
+        {
+          // Note: For "periodic" images, allocate one EmacsImage for
+          // the base image, and use it for all dh:s.
+          unsigned short *bits = p->bits;
+          int full_height = p->h + p->dh;
+          int i;
+          unsigned char *cbits = xmalloc (full_height);
+
+          for (i = 0; i < full_height; i++)
+            cbits[i] = bits[i];
+          img = [[EmacsImage alloc] initFromXBM: cbits width: 8
+                                         height: full_height
+                                             fg: 0 bg: 0];
+          bimgs[p->which - 1] = img;
+          xfree (cbits);
+        }
 
-          NSTRACE_RECT ("r", r);
+      NSTRACE_RECT ("r", r);
 
-          NSRectClip (r);
-          /* Since we composite the bitmap instead of just blitting it, we need
-             to erase the whole background.  */
-          [ns_lookup_indexed_color(face->background, f) set];
-          NSRectFill (r);
+      NSRectClip (r);
+      /* Since we composite the bitmap instead of just blitting it, we need
+         to erase the whole background. */
+      [ns_lookup_indexed_color(face->background, f) set];
+      NSRectFill (r);
 
-          {
-            NSColor *bm_color;
-            if (!p->cursor_p)
-              bm_color = ns_lookup_indexed_color(face->foreground, f);
-            else if (p->overlay_p)
-              bm_color = ns_lookup_indexed_color(face->background, f);
-            else
-              bm_color = f->output_data.ns->cursor_color;
-            [img setXBMColor: bm_color];
-          }
+      {
+        NSColor *bm_color;
+        if (!p->cursor_p)
+          bm_color = ns_lookup_indexed_color(face->foreground, f);
+        else if (p->overlay_p)
+          bm_color = ns_lookup_indexed_color(face->background, f);
+        else
+          bm_color = f->output_data.ns->cursor_color;
+        [img setXBMColor: bm_color];
+      }
 
 #ifdef NS_IMPL_COCOA
-          // Note: For periodic images, the full image height is "h + hd".
-          // By using the height h, a suitable part of the image is used.
-          NSRect fromRect = NSMakeRect(0, 0, p->wd, p->h);
-
-          NSTRACE_RECT ("fromRect", fromRect);
-
-          [img drawInRect: r
-                 fromRect: fromRect
-                operation: NSCompositingOperationSourceOver
-                 fraction: 1.0
-               respectFlipped: YES
-                    hints: nil];
+      // Note: For periodic images, the full image height is "h + hd".
+      // By using the height h, a suitable part of the image is used.
+      NSRect fromRect = NSMakeRect(0, 0, p->wd, p->h);
+
+      NSTRACE_RECT ("fromRect", fromRect);
+
+      [img drawInRect: r
+              fromRect: fromRect
+             operation: NSCompositingOperationSourceOver
+              fraction: 1.0
+           respectFlipped: YES
+                hints: nil];
 #else
-          {
-            NSPoint pt = r.origin;
-            pt.y += p->h;
-            [img compositeToPoint: pt operation: NSCompositingOperationSourceOver];
-          }
+      {
+        NSPoint pt = r.origin;
+        pt.y += p->h;
+        [img compositeToPoint: pt operation: NSCompositingOperationSourceOver];
+      }
 #endif
-        }
-      ns_reset_clipping (f);
     }
+  ns_unfocus (f);
 }
 
 
@@ -3092,66 +3120,67 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
   r.size.height = h;
   r.size.width = w->phys_cursor_width;
 
-  /* Prevent the cursor from being drawn outside the text area.  */
-  if (ns_clip_to_row (w, glyph_row, TEXT_AREA, NO))
+  /* Prevent the cursor from being drawn outside the text area. */
+  ns_clip_to_row (w, glyph_row, TEXT_AREA, NO); /* do ns_focus(f, &r, 1); if remove */
+
+
+  face = FACE_FROM_ID_OR_NULL (f, phys_cursor_glyph->face_id);
+  if (face && NS_FACE_BACKGROUND (face)
+      == ns_index_color (FRAME_CURSOR_COLOR (f), f))
     {
-      face = FACE_FROM_ID_OR_NULL (f, phys_cursor_glyph->face_id);
-      if (face && NS_FACE_BACKGROUND (face)
-          == ns_index_color (FRAME_CURSOR_COLOR (f), f))
-        {
-          [ns_lookup_indexed_color (NS_FACE_FOREGROUND (face), f) set];
-          hollow_color = FRAME_CURSOR_COLOR (f);
-        }
-      else
-        [FRAME_CURSOR_COLOR (f) set];
+      [ns_lookup_indexed_color (NS_FACE_FOREGROUND (face), f) set];
+      hollow_color = FRAME_CURSOR_COLOR (f);
+    }
+  else
+    [FRAME_CURSOR_COLOR (f) set];
 
 #ifdef NS_IMPL_COCOA
-      /* TODO: This makes drawing of cursor plus that of phys_cursor_glyph
-         atomic.  Cleaner ways of doing this should be investigated.
-         One way would be to set a global variable DRAWING_CURSOR
-         when making the call to draw_phys..(), don't focus in that
-         case, then move the ns_reset_clipping() here after that call.  */
-      NSDisableScreenUpdates ();
+  /* TODO: This makes drawing of cursor plus that of phys_cursor_glyph
+           atomic.  Cleaner ways of doing this should be investigated.
+           One way would be to set a global variable DRAWING_CURSOR
+  	   when making the call to draw_phys..(), don't focus in that
+  	   case, then move the ns_unfocus() here after that call. */
+  NSDisableScreenUpdates ();
 #endif
 
-      switch (cursor_type)
-        {
-        case DEFAULT_CURSOR:
-        case NO_CURSOR:
-          break;
-        case FILLED_BOX_CURSOR:
-          NSRectFill (r);
-          break;
-        case HOLLOW_BOX_CURSOR:
-          NSRectFill (r);
-          [hollow_color set];
-          NSRectFill (NSInsetRect (r, 1, 1));
-          [FRAME_CURSOR_COLOR (f) set];
-          break;
-        case HBAR_CURSOR:
-          NSRectFill (r);
-          break;
-        case BAR_CURSOR:
-          s = r;
-          /* If the character under cursor is R2L, draw the bar cursor
-             on the right of its glyph, rather than on the left.  */
-          cursor_glyph = get_phys_cursor_glyph (w);
-          if ((cursor_glyph->resolved_level & 1) != 0)
-            s.origin.x += cursor_glyph->pixel_width - s.size.width;
-
-          NSRectFill (s);
-          break;
-        }
-      ns_reset_clipping (f);
+  switch (cursor_type)
+    {
+    case DEFAULT_CURSOR:
+    case NO_CURSOR:
+      break;
+    case FILLED_BOX_CURSOR:
+      NSRectFill (r);
+      break;
+    case HOLLOW_BOX_CURSOR:
+      NSRectFill (r);
+      [hollow_color set];
+      NSRectFill (NSInsetRect (r, 1, 1));
+      [FRAME_CURSOR_COLOR (f) set];
+      break;
+    case HBAR_CURSOR:
+      NSRectFill (r);
+      break;
+    case BAR_CURSOR:
+      s = r;
+      /* If the character under cursor is R2L, draw the bar cursor
+         on the right of its glyph, rather than on the left.  */
+      cursor_glyph = get_phys_cursor_glyph (w);
+      if ((cursor_glyph->resolved_level & 1) != 0)
+        s.origin.x += cursor_glyph->pixel_width - s.size.width;
+
+      NSRectFill (s);
+      break;
+    }
+  ns_unfocus (f);
 
-      /* draw the character under the cursor */
-      if (cursor_type != NO_CURSOR)
-        draw_phys_cursor_glyph (w, glyph_row, DRAW_CURSOR);
+  /* draw the character under the cursor */
+  if (cursor_type != NO_CURSOR)
+    draw_phys_cursor_glyph (w, glyph_row, DRAW_CURSOR);
 
 #ifdef NS_IMPL_COCOA
-      NSEnableScreenUpdates ();
+  NSEnableScreenUpdates ();
 #endif
-    }
+
 }
 
 
@@ -3169,14 +3198,12 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
 
   face = FACE_FROM_ID_OR_NULL (f, VERTICAL_BORDER_FACE_ID);
 
-  if (ns_clip_to_rect (f, &r, 1))
-    {
-      if (face)
-        [ns_lookup_indexed_color(face->foreground, f) set];
+  ns_focus (f, &r, 1);
+  if (face)
+    [ns_lookup_indexed_color(face->foreground, f) set];
 
-      NSRectFill(r);
-      ns_reset_clipping (f);
-    }
+  NSRectFill(r);
+  ns_unfocus (f);
 }
 
 
@@ -3203,40 +3230,39 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
 
   NSTRACE ("ns_draw_window_divider");
 
-  if (ns_clip_to_rect (f, &divider, 1))
-    {
-      if ((y1 - y0 > x1 - x0) && (x1 - x0 >= 3))
-        /* A vertical divider, at least three pixels wide: Draw first and
-           last pixels differently.  */
-        {
-          [ns_lookup_indexed_color(color_first, f) set];
-          NSRectFill(NSMakeRect (x0, y0, 1, y1 - y0));
-          [ns_lookup_indexed_color(color, f) set];
-          NSRectFill(NSMakeRect (x0 + 1, y0, x1 - x0 - 2, y1 - y0));
-          [ns_lookup_indexed_color(color_last, f) set];
-          NSRectFill(NSMakeRect (x1 - 1, y0, 1, y1 - y0));
-        }
-      else if ((x1 - x0 > y1 - y0) && (y1 - y0 >= 3))
-        /* A horizontal divider, at least three pixels high: Draw first and
-           last pixels differently.  */
-        {
-          [ns_lookup_indexed_color(color_first, f) set];
-          NSRectFill(NSMakeRect (x0, y0, x1 - x0, 1));
-          [ns_lookup_indexed_color(color, f) set];
-          NSRectFill(NSMakeRect (x0, y0 + 1, x1 - x0, y1 - y0 - 2));
-          [ns_lookup_indexed_color(color_last, f) set];
-          NSRectFill(NSMakeRect (x0, y1 - 1, x1 - x0, 1));
-        }
-      else
-        {
-          /* In any other case do not draw the first and last pixels
-             differently.  */
-          [ns_lookup_indexed_color(color, f) set];
-          NSRectFill(divider);
-        }
+  ns_focus (f, &divider, 1);
 
-      ns_reset_clipping (f);
+  if ((y1 - y0 > x1 - x0) && (x1 - x0 >= 3))
+    /* A vertical divider, at least three pixels wide: Draw first and
+       last pixels differently.  */
+    {
+      [ns_lookup_indexed_color(color_first, f) set];
+      NSRectFill(NSMakeRect (x0, y0, 1, y1 - y0));
+      [ns_lookup_indexed_color(color, f) set];
+      NSRectFill(NSMakeRect (x0 + 1, y0, x1 - x0 - 2, y1 - y0));
+      [ns_lookup_indexed_color(color_last, f) set];
+      NSRectFill(NSMakeRect (x1 - 1, y0, 1, y1 - y0));
+    }
+  else if ((x1 - x0 > y1 - y0) && (y1 - y0 >= 3))
+    /* A horizontal divider, at least three pixels high: Draw first and
+       last pixels differently.  */
+    {
+      [ns_lookup_indexed_color(color_first, f) set];
+      NSRectFill(NSMakeRect (x0, y0, x1 - x0, 1));
+      [ns_lookup_indexed_color(color, f) set];
+      NSRectFill(NSMakeRect (x0, y0 + 1, x1 - x0, y1 - y0 - 2));
+      [ns_lookup_indexed_color(color_last, f) set];
+      NSRectFill(NSMakeRect (x0, y1 - 1, x1 - x0, 1));
+    }
+  else
+    {
+      /* In any other case do not draw the first and last pixels
+         differently.  */
+      [ns_lookup_indexed_color(color, f) set];
+      NSRectFill(divider);
     }
+
+  ns_unfocus (f);
 }
 
 static void
@@ -3820,84 +3846,83 @@ Function modeled after x_draw_glyph_string_box ().
       n = ns_get_glyph_string_clip_rect (s, r);
       *r = NSMakeRect (s->x, s->y, s->background_width, s->height);
 
-      if (ns_clip_to_rect (s->f, r, n))
+      ns_focus (s->f, r, n);
+
+      if (s->hl == DRAW_MOUSE_FACE)
+       {
+         face = FACE_FROM_ID_OR_NULL (s->f,
+				      MOUSE_HL_INFO (s->f)->mouse_face_face_id);
+         if (!face)
+           face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
+       }
+      else
+       face = FACE_FROM_ID (s->f, s->first_glyph->face_id);
+
+      bgCol = ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), s->f);
+      fgCol = ns_lookup_indexed_color (NS_FACE_FOREGROUND (face), s->f);
+
+      for (i = 0; i < n; ++i)
         {
-          if (s->hl == DRAW_MOUSE_FACE)
+          if (!s->row->full_width_p)
             {
-              face = FACE_FROM_ID_OR_NULL (s->f,
-                                           MOUSE_HL_INFO (s->f)->mouse_face_face_id);
-              if (!face)
-                face = FACE_FROM_ID (s->f, MOUSE_FACE_ID);
-            }
-          else
-            face = FACE_FROM_ID (s->f, s->first_glyph->face_id);
+	      int overrun, leftoverrun;
 
-          bgCol = ns_lookup_indexed_color (NS_FACE_BACKGROUND (face), s->f);
-          fgCol = ns_lookup_indexed_color (NS_FACE_FOREGROUND (face), s->f);
+              /* truncate to avoid overwriting fringe and/or scrollbar */
+	      overrun = max (0, (s->x + s->background_width)
+			     - (WINDOW_BOX_RIGHT_EDGE_X (s->w)
+				- WINDOW_RIGHT_FRINGE_WIDTH (s->w)));
+              r[i].size.width -= overrun;
 
-          for (i = 0; i < n; ++i)
-            {
-              if (!s->row->full_width_p)
-                {
-                  int overrun, leftoverrun;
-
-                  /* truncate to avoid overwriting fringe and/or scrollbar */
-                  overrun = max (0, (s->x + s->background_width)
-                                 - (WINDOW_BOX_RIGHT_EDGE_X (s->w)
-                                    - WINDOW_RIGHT_FRINGE_WIDTH (s->w)));
-                  r[i].size.width -= overrun;
-
-                  /* truncate to avoid overwriting to left of the window box */
-                  leftoverrun = (WINDOW_BOX_LEFT_EDGE_X (s->w)
-                                 + WINDOW_LEFT_FRINGE_WIDTH (s->w)) - s->x;
-
-                    if (leftoverrun > 0)
-                      {
-                        r[i].origin.x += leftoverrun;
-                        r[i].size.width -= leftoverrun;
-                      }
-
-                    /* XXX: Try to work between problem where a stretch glyph on
-                       a partially-visible bottom row will clear part of the
-                       modeline, and another where list-buffers headers and similar
-                       rows erroneously have visible_height set to 0.  Not sure
-                       where this is coming from as other terms seem not to show.  */
-                    r[i].size.height = min (s->height, s->row->visible_height);
-                }
+	      /* truncate to avoid overwriting to left of the window box */
+	      leftoverrun = (WINDOW_BOX_LEFT_EDGE_X (s->w)
+			     + WINDOW_LEFT_FRINGE_WIDTH (s->w)) - s->x;
 
-              [bgCol set];
+	      if (leftoverrun > 0)
+		{
+		  r[i].origin.x += leftoverrun;
+		  r[i].size.width -= leftoverrun;
+		}
 
-              /* NOTE: under NS this is NOT used to draw cursors, but we must avoid
-                 overwriting cursor (usually when cursor on a tab).  */
-              if (s->hl == DRAW_CURSOR)
-                {
-                  CGFloat x, width;
+              /* XXX: Try to work between problem where a stretch glyph on
+                 a partially-visible bottom row will clear part of the
+                 modeline, and another where list-buffers headers and similar
+                 rows erroneously have visible_height set to 0.  Not sure
+                 where this is coming from as other terms seem not to show. */
+              r[i].size.height = min (s->height, s->row->visible_height);
+            }
 
-                  x = r[i].origin.x;
-                  width = s->w->phys_cursor_width;
-                  r[i].size.width -= width;
-                  r[i].origin.x += width;
+          [bgCol set];
 
-                  NSRectFill (r[i]);
+          /* NOTE: under NS this is NOT used to draw cursors, but we must avoid
+             overwriting cursor (usually when cursor on a tab) */
+          if (s->hl == DRAW_CURSOR)
+            {
+              CGFloat x, width;
 
-                  /* Draw overlining, etc. on the cursor.  */
-                  if (s->w->phys_cursor_type == FILLED_BOX_CURSOR)
-                    ns_draw_text_decoration (s, face, bgCol, width, x);
-                  else
-                    ns_draw_text_decoration (s, face, fgCol, width, x);
-                }
-              else
-                {
-                  NSRectFill (r[i]);
-                }
+              x = r[i].origin.x;
+              width = s->w->phys_cursor_width;
+              r[i].size.width -= width;
+              r[i].origin.x += width;
+
+              NSRectFill (r[i]);
 
-              /* Draw overlining, etc. on the stretch glyph (or the part
-                 of the stretch glyph after the cursor).  */
-              ns_draw_text_decoration (s, face, fgCol, r[i].size.width,
-                                       r[i].origin.x);
+              /* Draw overlining, etc. on the cursor. */
+              if (s->w->phys_cursor_type == FILLED_BOX_CURSOR)
+                ns_draw_text_decoration (s, face, bgCol, width, x);
+              else
+                ns_draw_text_decoration (s, face, fgCol, width, x);
             }
-          ns_reset_clipping (s->f);
+          else
+            {
+              NSRectFill (r[i]);
+            }
+
+          /* Draw overlining, etc. on the stretch glyph (or the part
+             of the stretch glyph after the cursor). */
+          ns_draw_text_decoration (s, face, fgCol, r[i].size.width,
+                                   r[i].origin.x);
         }
+      ns_unfocus (s->f);
       s->background_filled_p = 1;
     }
 }
@@ -4047,11 +4072,9 @@ overwriting cursor (usually when cursor on a tab).  */
             if (next->first_glyph->type != STRETCH_GLYPH)
               {
                 n = ns_get_glyph_string_clip_rect (s->next, r);
-                if (ns_clip_to_rect (s->f, r, n))
-                  {
-                    ns_maybe_dumpglyphs_background (s->next, 1);
-                    ns_reset_clipping (s->f);
-                  }
+                ns_focus (s->f, r, n);
+                ns_maybe_dumpglyphs_background (s->next, 1);
+                ns_unfocus (s->f);
               }
             else
               {
@@ -4066,12 +4089,10 @@ overwriting cursor (usually when cursor on a tab).  */
 	    || s->first_glyph->type == COMPOSITE_GLYPH))
     {
       n = ns_get_glyph_string_clip_rect (s, r);
-      if (ns_clip_to_rect (s->f, r, n))
-        {
-          ns_maybe_dumpglyphs_background (s, 1);
-          ns_dumpglyphs_box_or_relief (s);
-          ns_reset_clipping (s->f);
-        }
+      ns_focus (s->f, r, n);
+      ns_maybe_dumpglyphs_background (s, 1);
+      ns_dumpglyphs_box_or_relief (s);
+      ns_unfocus (s->f);
       box_drawn_p = 1;
     }
 
@@ -4080,11 +4101,9 @@ overwriting cursor (usually when cursor on a tab).  */
 
     case IMAGE_GLYPH:
       n = ns_get_glyph_string_clip_rect (s, r);
-      if (ns_clip_to_rect (s->f, r, n))
-        {
-          ns_dumpglyphs_image (s, r[0]);
-          ns_reset_clipping (s->f);
-        }
+      ns_focus (s->f, r, n);
+      ns_dumpglyphs_image (s, r[0]);
+      ns_unfocus (s->f);
       break;
 
     case STRETCH_GLYPH:
@@ -4094,68 +4113,66 @@ overwriting cursor (usually when cursor on a tab).  */
     case CHAR_GLYPH:
     case COMPOSITE_GLYPH:
       n = ns_get_glyph_string_clip_rect (s, r);
-      if (ns_clip_to_rect (s->f, r, n))
-        {
-          if (s->for_overlaps || (s->cmp_from > 0
-                                  && ! s->first_glyph->u.cmp.automatic))
-            s->background_filled_p = 1;
-          else
-            ns_maybe_dumpglyphs_background
-              (s, s->first_glyph->type == COMPOSITE_GLYPH);
+      ns_focus (s->f, r, n);
 
-          if (s->hl == DRAW_CURSOR && s->w->phys_cursor_type == FILLED_BOX_CURSOR)
-            {
-              unsigned long tmp = NS_FACE_BACKGROUND (s->face);
-              NS_FACE_BACKGROUND (s->face) = NS_FACE_FOREGROUND (s->face);
-              NS_FACE_FOREGROUND (s->face) = tmp;
-            }
+      if (s->for_overlaps || (s->cmp_from > 0
+			      && ! s->first_glyph->u.cmp.automatic))
+        s->background_filled_p = 1;
+      else
+        ns_maybe_dumpglyphs_background
+          (s, s->first_glyph->type == COMPOSITE_GLYPH);
 
-          {
-            BOOL isComposite = s->first_glyph->type == COMPOSITE_GLYPH;
+      if (s->hl == DRAW_CURSOR && s->w->phys_cursor_type == FILLED_BOX_CURSOR)
+        {
+          unsigned long tmp = NS_FACE_BACKGROUND (s->face);
+          NS_FACE_BACKGROUND (s->face) = NS_FACE_FOREGROUND (s->face);
+          NS_FACE_FOREGROUND (s->face) = tmp;
+        }
 
-            if (isComposite)
-              ns_draw_composite_glyph_string_foreground (s);
-            else
-              ns_draw_glyph_string_foreground (s);
-          }
+      {
+        BOOL isComposite = s->first_glyph->type == COMPOSITE_GLYPH;
 
-          {
-            NSColor *col = (NS_FACE_FOREGROUND (s->face) != 0
-                            ? ns_lookup_indexed_color (NS_FACE_FOREGROUND (s->face),
-                                                       s->f)
-                            : FRAME_FOREGROUND_COLOR (s->f));
-            [col set];
-
-            /* Draw underline, overline, strike-through.  */
-            ns_draw_text_decoration (s, s->face, col, s->width, s->x);
-          }
+        if (isComposite)
+          ns_draw_composite_glyph_string_foreground (s);
+        else
+          ns_draw_glyph_string_foreground (s);
+      }
 
-          if (s->hl == DRAW_CURSOR && s->w->phys_cursor_type == FILLED_BOX_CURSOR)
-            {
-              unsigned long tmp = NS_FACE_BACKGROUND (s->face);
-              NS_FACE_BACKGROUND (s->face) = NS_FACE_FOREGROUND (s->face);
-              NS_FACE_FOREGROUND (s->face) = tmp;
-            }
+      {
+        NSColor *col = (NS_FACE_FOREGROUND (s->face) != 0
+                        ? ns_lookup_indexed_color (NS_FACE_FOREGROUND (s->face),
+                                                   s->f)
+                        : FRAME_FOREGROUND_COLOR (s->f));
+        [col set];
+
+        /* Draw underline, overline, strike-through. */
+        ns_draw_text_decoration (s, s->face, col, s->width, s->x);
+      }
 
-          ns_reset_clipping (s->f);
+      if (s->hl == DRAW_CURSOR && s->w->phys_cursor_type == FILLED_BOX_CURSOR)
+        {
+          unsigned long tmp = NS_FACE_BACKGROUND (s->face);
+          NS_FACE_BACKGROUND (s->face) = NS_FACE_FOREGROUND (s->face);
+          NS_FACE_FOREGROUND (s->face) = tmp;
         }
+
+      ns_unfocus (s->f);
       break;
 
     case GLYPHLESS_GLYPH:
       n = ns_get_glyph_string_clip_rect (s, r);
-      if (ns_clip_to_rect (s->f, r, n))
-        {
-          if (s->for_overlaps || (s->cmp_from > 0
-                                  && ! s->first_glyph->u.cmp.automatic))
-            s->background_filled_p = 1;
-          else
-            ns_maybe_dumpglyphs_background
-              (s, s->first_glyph->type == COMPOSITE_GLYPH);
-          /* ... */
-          /* Not yet implemented.  */
-          /* ... */
-          ns_reset_clipping (s->f);
-        }
+      ns_focus (s->f, r, n);
+
+      if (s->for_overlaps || (s->cmp_from > 0
+			      && ! s->first_glyph->u.cmp.automatic))
+        s->background_filled_p = 1;
+      else
+        ns_maybe_dumpglyphs_background
+          (s, s->first_glyph->type == COMPOSITE_GLYPH);
+      /* ... */
+      /* Not yet implemented.  */
+      /* ... */
+      ns_unfocus (s->f);
       break;
 
     default:
@@ -4166,11 +4183,9 @@ overwriting cursor (usually when cursor on a tab).  */
   if (!s->for_overlaps && !box_drawn_p && s->face->box != FACE_NO_BOX)
     {
       n = ns_get_glyph_string_clip_rect (s, r);
-      if (ns_clip_to_rect (s->f, r, n))
-        {
-          ns_dumpglyphs_box_or_relief (s);
-          ns_reset_clipping (s->f);
-        }
+      ns_focus (s->f, r, n);
+      ns_dumpglyphs_box_or_relief (s);
+      ns_unfocus (s->f);
     }
 
   s->num_clips = 0;
@@ -4976,7 +4991,7 @@ static Lisp_Object ns_string_to_lispmod (const char *s)
   ns_after_update_window_line,
   ns_update_window_begin,
   ns_update_window_end,
-  ns_flush_display, /* flush_display */
+  0, /* flush_display */
   x_clear_window_mouse_face,
   x_get_glyph_overhangs,
   x_fix_overlapping_area,
-- 
2.19.1


From 812d2b6dbb3eb254736fd6161895d319b5d74b07 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Tue, 13 Nov 2018 21:58:45 +0000
Subject: [PATCH 4/4] That was almost too easy

---
 src/nsterm.h |   3 ++
 src/nsterm.m | 135 ++++++++++++++++++++++++++++++---------------------
 2 files changed, 83 insertions(+), 55 deletions(-)

diff --git a/src/nsterm.h b/src/nsterm.h
index 588b9fc644..034da58d9c 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -423,6 +423,7 @@ typedef id instancetype;
    EmacsToolbar *toolbar;
    NSRect ns_userRect;
    BOOL wait_for_tool_bar;
+   NSBitmapImageRep *drawingBuffer;
    }
 
 /* AppKit-side interface */
@@ -456,6 +457,8 @@ typedef id instancetype;
 #endif
 - (int)fullscreenState;
 
+- (void)focusOnDrawingBuffer;
+
 /* Non-notification versions of NSView methods. Used for direct calls. */
 - (void)windowWillEnterFullScreen;
 - (void)windowDidEnterFullScreen;
diff --git a/src/nsterm.m b/src/nsterm.m
index abb80c9938..107c8d98b4 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -277,7 +277,6 @@ - (NSColor *)colorUsingDefaultColorSpace
 
 /* display update */
 static struct frame *ns_updating_frame;
-static NSView *focus_view = NULL;
 static int ns_window_num = 0;
 #ifdef NS_IMPL_GNUSTEP
 static NSRect uRect;            // TODO: This is dead, remove it?
@@ -1056,7 +1055,7 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 #endif
 
   ns_updating_frame = f;
-  [view lockFocus];
+  [view focusOnDrawingBuffer];
 
   /* drawRect may have been called for say the minibuffer, and then clip path
      is for the minibuffer.  But the display engine may draw more because
@@ -1168,15 +1167,12 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 
   NSTRACE_WHEN (NSTRACE_GROUP_UPDATES, "ns_update_end");
 
+  [[NSGraphicsContext currentContext] flushGraphics];
+  [view setNeedsDisplay:YES];
+
 /*   if (f == MOUSE_HL_INFO (f)->mouse_face_mouse_frame) */
   MOUSE_HL_INFO (f)->mouse_face_defer = 0;
 
-  block_input ();
-
-  [view unlockFocus];
-  [[view window] flushWindow];
-
-  unblock_input ();
   ns_updating_frame = NULL;
 }
 
@@ -1200,20 +1196,8 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
   if (f != ns_updating_frame)
     {
       NSView *view = FRAME_NS_VIEW (f);
-      if (view != focus_view)
-        {
-          if (focus_view != NULL)
-            {
-              [focus_view unlockFocus];
-              [[focus_view window] flushWindow];
-/*debug_lock--; */
-            }
-
-          if (view)
-            [view lockFocus];
-          focus_view = view;
-/*if (view) debug_lock++; */
-        }
+      if (view)
+        [view focusOnDrawingBuffer];
     }
 
   /* clipping */
@@ -1242,17 +1226,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
       [[NSGraphicsContext currentContext] restoreGraphicsState];
       gsaved = NO;
     }
-
-  if (f != ns_updating_frame)
-    {
-      if (focus_view != NULL)
-        {
-          [focus_view unlockFocus];
-          [[focus_view window] flushWindow];
-          focus_view = NULL;
-/*debug_lock--; */
-        }
-    }
 }
 
 
@@ -2736,22 +2709,6 @@ so some key presses (TAB) are swallowed by the system. */
   return;
 }
 
-static void
-ns_copy_bits (struct frame *f, NSRect src, NSRect dest)
-{
-  NSTRACE ("ns_copy_bits");
-
-  if (FRAME_NS_VIEW (f))
-    {
-      hide_bell();              // Ensure the bell image isn't scrolled.
-
-      ns_focus (f, &dest, 1);
-      [FRAME_NS_VIEW (f) scrollRect: src
-                                 by: NSMakeSize (dest.origin.x - src.origin.x,
-                                                 dest.origin.y - src.origin.y)];
-      ns_unfocus (f);
-    }
-}
 
 static void
 ns_scroll_run (struct window *w, struct run *run)
@@ -2805,7 +2762,7 @@ so some key presses (TAB) are swallowed by the system. */
     NSRect srcRect = NSMakeRect (x, from_y, width, height);
     NSRect dstRect = NSMakeRect (x, to_y, width, height);
 
-    ns_copy_bits (f, srcRect , dstRect);
+    [FRAME_NS_VIEW (f) copyDrawingBufferRect:srcRect To:dstRect];
   }
 
   unblock_input ();
@@ -2864,7 +2821,7 @@ so some key presses (TAB) are swallowed by the system. */
 
   NSTRACE ("ns_shift_glyphs_for_insert");
 
-  ns_copy_bits (f, srcRect, dstRect);
+  [FRAME_NS_VIEW (f) copyDrawingBufferRect:srcRect To:dstRect];
 }
 
 
@@ -6978,6 +6935,7 @@ - (void) updateFrameSize: (BOOL) delay
          from non-native fullscreen, in other circumstances it appears
          to be a noop.  (bug#28872) */
       wr = NSMakeRect (0, 0, neww, newh);
+      [view createDrawingBufferWithRect:wr];
       [view setFrame: wr];
 
       // to do: consider using [NSNotificationCenter postNotificationName:].
@@ -7248,6 +7206,74 @@ - (BOOL)isOpaque
 }
 
 
+- (void)windowDidChangeBackingProperties:(NSNotification *)notification
+  /* Update the drawing buffer when the backing scale factor changes.  */
+{
+   CGFloat old = [[[notification userInfo]
+                    objectForKey:@"NSBackingPropertyOldScaleFactorKey"]
+                   doubleValue];
+   CGFloat new = [[self window] backingScaleFactor];
+
+   if (old != new)
+     {
+       NSRect frame = [self frame];
+       [self createDrawingBufferWithRect:frame];
+       ns_clear_frame (emacsframe);
+       expose_frame (emacsframe, 0, 0, NSWidth (frame), NSHeight (frame));
+     }
+}
+
+
+- (void)createDrawingBufferWithRect:(NSRect)rect
+  /* Create and store a new NSBitmapImageRep for Emacs to draw
+     into.  */
+{
+  NSRect backingRect;
+
+  if (drawingBuffer != nil)
+    [drawingBuffer release];
+
+  backingRect = [self convertRectToBacking:rect];
+
+  drawingBuffer = [[NSBitmapImageRep alloc] initWithBitmapDataPlanes:nil
+                                                          pixelsWide:NSWidth (backingRect)
+                                                          pixelsHigh:NSHeight (backingRect)
+                                                       bitsPerSample:8
+                                                     samplesPerPixel:4
+                                                            hasAlpha:YES
+                                                            isPlanar:NO
+                                                      colorSpaceName:NSCalibratedRGBColorSpace
+                                                        bitmapFormat:0
+                                                         bytesPerRow:(4 * NSWidth (backingRect))
+                                                        bitsPerPixel:32];
+
+  [drawingBuffer setSize:rect.size];
+}
+
+
+- (void)focusOnDrawingBuffer
+{
+  [NSGraphicsContext setCurrentContext:
+                       [NSGraphicsContext graphicsContextWithBitmapImageRep:drawingBuffer]];
+}
+
+
+- (void)copyDrawingBufferRect:(NSRect)srcRect To:(NSRect)dstRect
+{
+  NSTRACE ("[EmacsView copyDrawingBufferRect:To:]");
+  NSTRACE_RECT ("SOURCE", srcRect);
+  NSTRACE_RECT ("Destination", dstRect);
+
+  [self focusOnDrawingBuffer];
+  [drawingBuffer drawInRect:dstRect
+                   fromRect:srcRect
+                  operation:NSCompositingOperationCopy
+                   fraction:1.0
+             respectFlipped:YES
+                      hints:nil];
+}
+
+
 - (void)createToolbar: (struct frame *)f
 {
   EmacsView *view = (EmacsView *)FRAME_NS_VIEW (f);
@@ -7317,6 +7343,8 @@ - (instancetype) initFrameFromEmacs: (struct frame *)f
   maximizing_resize = NO;
 #endif
 
+  [self createDrawingBufferWithRect:r];
+
   win = [[EmacsWindow alloc]
             initWithContentRect: r
                       styleMask: (FRAME_UNDECORATED (f)
@@ -8118,10 +8146,7 @@ - (void)drawRect: (NSRect)rect
   if (!emacsframe || !emacsframe->output_data.ns)
     return;
 
-  ns_clear_frame_area (emacsframe, x, y, width, height);
-  block_input ();
-  expose_frame (emacsframe, x, y, width, height);
-  unblock_input ();
+  [drawingBuffer draw];
 
   /*
     drawRect: may be called (at least in Mac OS X 10.5) for invisible
-- 
2.19.1

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Aaron Jensen]

On November 13, 2018 at 2:13:41 PM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> OK, so all new patch. It should apply to emacs-26 without any
> additional patches (and might be OK for master too). Just the usual
> ’git am’ should apply all four, I believe.

I’m not sure if I’m doing something wrong, but git am stops after
applying 2 commits and leaves me with a dirty tree (src/nsterm.m is
staged). I’ve tried on emacs-26 and master.

$ g am draw-to-buffer.mbox
Applying: Revert "Fix some NS drawing issues (bug#32932)"
Applying: Revert "Ensure NS frame is redrawn correctly after scroll"
Applying: Revert "Make all NS drawing be done from drawRect"
.git/rebase-apply/patch:493: space before tab in indent.
           when making the call to draw_phys..(), don't focus in that
.git/rebase-apply/patch:494: space before tab in indent.
           case, then move the ns_unfocus() here after that call. */
warning: 2 lines add whitespace errors.
src/nsterm.m:3141: space before tab in indent.
+          when making the call to draw_phys..(), don't focus in that
src/nsterm.m:3142: space before tab in indent.
+          case, then move the ns_unfocus() here after that call. */

After this, git am --continue simply repeats the last set of warnings.

Aaron

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

I suspect that's due to the whitespace checks that the Emacs tree builds
into git. I know there's a way to disable them, but I don't know what.

You could just try reverting the commits yourself and then extracting the
4th patch from the file and applying it.

On Wed, 14 Nov 2018, 17:09 Aaron Jensen <aaronjensen@gmail.com wrote:

> On November 13, 2018 at 2:13:41 PM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
>
> > OK, so all new patch. It should apply to emacs-26 without any
> > additional patches (and might be OK for master too). Just the usual
> > ’git am’ should apply all four, I believe.
>
> I’m not sure if I’m doing something wrong, but git am stops after
> applying 2 commits and leaves me with a dirty tree (src/nsterm.m is
> staged). I’ve tried on emacs-26 and master.
>
> $ g am draw-to-buffer.mbox
> Applying: Revert "Fix some NS drawing issues (bug#32932)"
> Applying: Revert "Ensure NS frame is redrawn correctly after scroll"
> Applying: Revert "Make all NS drawing be done from drawRect"
> .git/rebase-apply/patch:493: space before tab in indent.
>            when making the call to draw_phys..(), don't focus in that
> .git/rebase-apply/patch:494: space before tab in indent.
>            case, then move the ns_unfocus() here after that call. */
> warning: 2 lines add whitespace errors.
> src/nsterm.m:3141: space before tab in indent.
> +          when making the call to draw_phys..(), don't focus in that
> src/nsterm.m:3142: space before tab in indent.
> +          case, then move the ns_unfocus() here after that call. */
>
> After this, git am --continue simply repeats the last set of warnings.
>
> Aaron
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Aaron Jensen]

On November 14, 2018 at 10:19:39 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> I suspect that's due to the whitespace checks that the Emacs tree builds into git. I know there's a way to disable them, but I don't know what.
>
> You could just try reverting the commits yourself and then extracting the 4th patch from the file and applying it.

Okay, I was able to apply them. It renders a blank frame, however.

Aaron

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Alan Third]

On Thu, Nov 15, 2018 at 05:20:09PM -0800, Aaron Jensen wrote:
> On November 14, 2018 at 10:19:39 AM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> 
> > I suspect that's due to the whitespace checks that the Emacs tree
> > builds into git. I know there's a way to disable them, but I don't
> > know what.
> >
> > You could just try reverting the commits yourself and then
> > extracting the 4th patch from the file and applying it.
> 
> Okay, I was able to apply them. It renders a blank frame, however.

Today I realised I’m able to install Mojave on an external HDD without
affecting my High Sierra install, so I gave it a go and this patch
works, so I guess it maybe didn’t apply correctly. Perhaps it doesn’t
apply to master?

Given that Emacs 26.2 is in pre‐release now I’m inclined to leave
emacs-26 as‐is for now, unless we require the 8th of November patch
(Further changes to NS drawing (bug#32932))? I don’t think we do as
iirc it just solves a minor redrawing issue (i.e. Emacs is still
usable without it). Is that right?
-- 
Alan Third

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Aaron Jensen]

On November 19, 2018 at 2:35:51 PM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> On Thu, Nov 15, 2018 at 05:20:09PM -0800, Aaron Jensen wrote:
> > On November 14, 2018 at 10:19:39 AM, Alan Third
> > (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> >
> > > I suspect that's due to the whitespace checks that the Emacs tree
> > > builds into git. I know there's a way to disable them, but I don't
> > > know what.
> > >
> > > You could just try reverting the commits yourself and then
> > > extracting the 4th patch from the file and applying it.
> >
> > Okay, I was able to apply them. It renders a blank frame, however.
>
> Today I realised I’m able to install Mojave on an external HDD without
> affecting my High Sierra install, so I gave it a go and this patch
> works, so I guess it maybe didn’t apply correctly. Perhaps it doesn’t
> apply to master?

Oh, good I’m glad you're able to test it now. I was able to get the
patch to apply properly by deleting everything in .git/hooks and then
applying your patch to emacs-26. I was then able to merge that to
master and it worked.

It is, however, unusably slow. The performance degrades more the
bigger the frame is. I’ve gone back to what I was using before (master
+ the patch you reference below).

> Given that Emacs 26.2 is in pre‐release now I’m inclined to leave
> emacs-26 as‐is for now, unless we require the 8th of November patch
> (Further changes to NS drawing (bug#32932))? I don’t think we do as
> iirc it just solves a minor redrawing issue (i.e. Emacs is still
> usable without it). Is that right?

Yes, it is still usable, though if I remember correctly it lessens the
overall blank glitches (which still happen even w/ the patch). So yes,
it’s usable, but you do occasionally have to resize the window or do
something else to get it to repaint. You still have to w/ the patch,
just less often.

Thanks,

Aaron

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

On Mon, Nov 19, 2018 at 06:30:05PM -0800, Aaron Jensen wrote:
> On November 19, 2018 at 2:35:51 PM, Alan Third
> (alan@idiocy.org(mailto:alan@idiocy.org)) wrote:
> 
> > Given that Emacs 26.2 is in pre‐release now I’m inclined to leave
> > emacs-26 as‐is for now, unless we require the 8th of November patch
> > (Further changes to NS drawing (bug#32932))? I don’t think we do as
> > iirc it just solves a minor redrawing issue (i.e. Emacs is still
> > usable without it). Is that right?
> 
> Yes, it is still usable, though if I remember correctly it lessens the
> overall blank glitches (which still happen even w/ the patch). So yes,
> it’s usable, but you do occasionally have to resize the window or do
> something else to get it to repaint. You still have to w/ the patch,
> just less often.

Final (hopefully) version of this patch attached.

I guess there are still issues with it, but we’re running out of time
to sort them for Emacs 26.2.

From a practical stand point I don’t think this is really any
different from the last one, but it has some comment changes and a
change to how we handle requests to copy parts of the screen, since
they were the major issue still with ghosting cursors.

I probably need to double check it’s OK on GNUstep, but I don’t
foresee any issues there.
-- 
Alan Third

[-- Attachment #2: v3-0001-Fix-more-drawing-bugs-in-NS-port-bug-32932.patch --]
[-- Type: text/plain, Size: 11236 bytes --]

From a55e5259341e054023727de4dc86b77c7a7d5db6 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Mon, 29 Oct 2018 15:37:35 +0000
Subject: [PATCH v3] Fix more drawing bugs in NS port (bug#32932)

* src/nsterm.m (ns_row_rect): New function.
(ns_clip_to_row): Remove function.
(ns_copy_bits): Fix mistake.
(ns_shift_glyphs_for_insert): Mark the frame as dirty instead of
directly copying.
(ns_draw_fringe_bitmap): Stop using ns_clip_to_row.
(ns_draw_window_cursor): Stop using ns_clip_to_row and perform a
display when not in redisplay.
(ns_update_window_begin): Remove redundant code that never executes.
([EmacsView drawRect:]): Show the rectangle being exposed in NSTRACE.
* src/xdisp.c (expose_window_tree) [HAVE_NS]:
(expose_frame) [HAVE_NS]: Redraw even if the frame is garbaged.
---
 src/nsterm.m | 149 +++++++++++++++++++++++++++------------------------
 src/xdisp.c  |  15 +++++-
 2 files changed, 91 insertions(+), 73 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 4b5d025ee3..948dd1da2e 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -796,6 +796,27 @@ Free a pool and temporary objects it refers to (callable from C)
 }
 
 
+static NSRect
+ns_row_rect (struct window *w, struct glyph_row *row,
+               enum glyph_row_area area)
+/* Get the row as an NSRect.  */
+{
+  struct frame *f = XFRAME (WINDOW_FRAME (w));
+  NSRect rect;
+  int window_x, window_y, window_width;
+
+  window_box (w, area, &window_x, &window_y, &window_width, 0);
+
+  rect.origin.x = window_x;
+  rect.origin.y = WINDOW_TO_FRAME_PIXEL_Y (w, max (0, row->y));
+  rect.origin.y = max (rect.origin.y, window_y);
+  rect.size.width = window_width;
+  rect.size.height = row->visible_height;
+
+  return rect;
+}
+
+
 /* ==========================================================================
 
     Focus (clipping) and screen update
@@ -1048,29 +1069,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
     if (! tbar_visible != ! [toolbar isVisible])
       [toolbar setVisible: tbar_visible];
   }
-
-  /* drawRect may have been called for say the minibuffer, and then clip path
-     is for the minibuffer.  But the display engine may draw more because
-     we have set the frame as garbaged.  So reset clip path to the whole
-     view.  */
-  /* FIXME: I don't think we need to do this.  */
-  if ([NSView focusView] == FRAME_NS_VIEW (f))
-    {
-      NSBezierPath *bp;
-      NSRect r = [view frame];
-      NSRect cr = [[view window] frame];
-      /* If a large frame size is set, r may be larger than the window frame
-         before constrained.  In that case don't change the clip path, as we
-         will clear in to the tool bar and title bar.  */
-      if (r.size.height
-          + FRAME_NS_TITLEBAR_HEIGHT (f)
-          + FRAME_TOOLBAR_HEIGHT (f) <= cr.size.height)
-        {
-          bp = [[NSBezierPath bezierPathWithRect: r] retain];
-          [bp setClip];
-          [bp release];
-        }
-    }
 #endif
 }
 
@@ -1206,28 +1204,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 }
 
 
-static BOOL
-ns_clip_to_row (struct window *w, struct glyph_row *row,
-		enum glyph_row_area area, BOOL gc)
-/* --------------------------------------------------------------------------
-     Internal (but parallels other terms): Focus drawing on given row
-   -------------------------------------------------------------------------- */
-{
-  struct frame *f = XFRAME (WINDOW_FRAME (w));
-  NSRect clip_rect;
-  int window_x, window_y, window_width;
-
-  window_box (w, area, &window_x, &window_y, &window_width, 0);
-
-  clip_rect.origin.x = window_x;
-  clip_rect.origin.y = WINDOW_TO_FRAME_PIXEL_Y (w, max (0, row->y));
-  clip_rect.origin.y = max (clip_rect.origin.y, window_y);
-  clip_rect.size.width = window_width;
-  clip_rect.size.height = row->visible_height;
-
-  return ns_clip_to_rect (f, &clip_rect, 1);
-}
-
 /* ==========================================================================
 
     Visible bell and beep.
@@ -2692,7 +2668,7 @@ so some key presses (TAB) are swallowed by the system. */
 ns_copy_bits (struct frame *f, NSRect src, NSRect dest)
 {
   NSSize delta = NSMakeSize (dest.origin.x - src.origin.x,
-                             dest.origin.y - src.origin.y)
+                             dest.origin.y - src.origin.y);
   NSTRACE ("ns_copy_bits");
 
   if (FRAME_NS_VIEW (f))
@@ -2825,12 +2801,20 @@ so some key presses (TAB) are swallowed by the system. */
     External (RIF): copy an area horizontally, don't worry about clearing src
    -------------------------------------------------------------------------- */
 {
-  NSRect srcRect = NSMakeRect (x, y, width, height);
+  //NSRect srcRect = NSMakeRect (x, y, width, height);
   NSRect dstRect = NSMakeRect (x+shift_by, y, width, height);
 
   NSTRACE ("ns_shift_glyphs_for_insert");
 
-  ns_copy_bits (f, srcRect, dstRect);
+  /* This doesn't work now as we copy the "bits" before we've had a
+     chance to actually draw any changes to the screen.  This means in
+     certain circumstances we end up with copies of the cursor all
+     over the place.  Just mark the area dirty so it is redrawn later.
+
+     FIXME: Work out how to do this properly.  */
+  // ns_copy_bits (f, srcRect, dstRect);
+
+  [FRAME_NS_VIEW (f) setNeedsDisplayInRect:dstRect];
 }
 
 
@@ -2911,6 +2895,9 @@ so some key presses (TAB) are swallowed by the system. */
   struct face *face = p->face;
   static EmacsImage **bimgs = NULL;
   static int nBimgs = 0;
+  NSRect clearRect = NSZeroRect;
+  NSRect imageRect = NSZeroRect;
+  NSRect rowRect = ns_row_rect (w, row, ANY_AREA);
 
   NSTRACE_WHEN (NSTRACE_GROUP_FRINGE, "ns_draw_fringe_bitmap");
   NSTRACE_MSG ("which:%d cursor:%d overlay:%d width:%d height:%d period:%d",
@@ -2925,25 +2912,40 @@ so some key presses (TAB) are swallowed by the system. */
       nBimgs = max_used_fringe_bitmap;
     }
 
-  /* Must clip because of partially visible lines.  */
-  if (ns_clip_to_row (w, row, ANY_AREA, YES))
+  /* Work out the rectangle we will composite into.  */
+  if (p->which)
+    imageRect = NSMakeRect (p->x, p->y, p->wd, p->h);
+
+  /* Work out the rectangle we will need to clear.  Because we're
+     compositing rather than blitting, we need to clear the area under
+     the image regardless of anything else.  */
+  if (!p->overlay_p)
+    {
+      clearRect = NSMakeRect (p->bx, p->by, p->nx, p->ny);
+      clearRect = NSUnionRect (clearRect, imageRect);
+    }
+  else
+    {
+      clearRect = imageRect;
+    }
+
+  /* Handle partially visible rows.  */
+  clearRect = NSIntersectionRect (clearRect, rowRect);
+
+  /* The visible portion of imageRect will always be contained within
+     clearRect.  */
+  if (ns_clip_to_rect (f, &clearRect, 1))
     {
-      if (!p->overlay_p)
+      if (! NSIsEmptyRect (clearRect))
         {
-          int bx = p->bx, by = p->by, nx = p->nx, ny = p->ny;
+          NSTRACE_RECT ("clearRect", clearRect);
 
-          if (bx >= 0 && nx > 0)
-            {
-              NSRect r = NSMakeRect (bx, by, nx, ny);
-              NSRectClip (r);
-              [ns_lookup_indexed_color (face->background, f) set];
-              NSRectFill (r);
-            }
+          [ns_lookup_indexed_color(face->background, f) set];
+          NSRectFill (clearRect);
         }
 
       if (p->which)
         {
-          NSRect r = NSMakeRect (p->x, p->y, p->wd, p->h);
           EmacsImage *img = bimgs[p->which - 1];
 
           if (!img)
@@ -2964,13 +2966,6 @@ so some key presses (TAB) are swallowed by the system. */
               xfree (cbits);
             }
 
-          NSTRACE_RECT ("r", r);
-
-          NSRectClip (r);
-          /* Since we composite the bitmap instead of just blitting it, we need
-             to erase the whole background.  */
-          [ns_lookup_indexed_color(face->background, f) set];
-          NSRectFill (r);
 
           {
             NSColor *bm_color;
@@ -2990,7 +2985,7 @@ so some key presses (TAB) are swallowed by the system. */
 
           NSTRACE_RECT ("fromRect", fromRect);
 
-          [img drawInRect: r
+          [img drawInRect: imageRect
                  fromRect: fromRect
                 operation: NSCompositingOperationSourceOver
                  fraction: 1.0
@@ -2998,7 +2993,7 @@ so some key presses (TAB) are swallowed by the system. */
                     hints: nil];
 #else
           {
-            NSPoint pt = r.origin;
+            NSPoint pt = imageRect.origin;
             pt.y += p->h;
             [img compositeToPoint: pt operation: NSCompositingOperationSourceOver];
           }
@@ -3088,7 +3083,9 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
   r.size.width = w->phys_cursor_width;
 
   /* Prevent the cursor from being drawn outside the text area.  */
-  if (ns_clip_to_row (w, glyph_row, TEXT_AREA, NO))
+  r = NSIntersectionRect (r, ns_row_rect (w, glyph_row, TEXT_AREA));
+
+  if (ns_clip_to_rect (f, &r, 1))
     {
       face = FACE_FROM_ID_OR_NULL (f, phys_cursor_glyph->face_id);
       if (face && NS_FACE_BACKGROUND (face)
@@ -3128,11 +3125,18 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
           NSRectFill (s);
           break;
         }
-      ns_reset_clipping (f);
 
       /* draw the character under the cursor */
       if (cursor_type != NO_CURSOR)
         draw_phys_cursor_glyph (w, glyph_row, DRAW_CURSOR);
+
+      ns_reset_clipping (f);
+    }
+  else if (! redisplaying_p)
+    {
+      /* If this function is called outside redisplay, it probably
+         means we need an immediate update.  */
+      [FRAME_NS_VIEW (f) display];
     }
 }
 
@@ -8096,6 +8100,9 @@ - (void)drawRect: (NSRect)rect
   for (int i = 0 ; i < numRects ; i++)
     {
       NSRect r = rectList[i];
+
+      NSTRACE_RECT ("r", r);
+
       expose_frame (emacsframe,
                     NSMinX (r), NSMinY (r),
                     NSWidth (r), NSHeight (r));
diff --git a/src/xdisp.c b/src/xdisp.c
index 357f0fb30c..808eab7e53 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -32258,7 +32258,14 @@ expose_window_tree (struct window *w, XRectangle *r)
   struct frame *f = XFRAME (w->frame);
   bool mouse_face_overwritten_p = false;
 
-  while (w && !FRAME_GARBAGED_P (f))
+  /* NS toolkits may have aleady modified the frame in expectation of
+     a successful redraw, so don't bail out here if the frame is
+     garbaged.  */
+  while (w
+#if !defined (HAVE_NS)
+         && !FRAME_GARBAGED_P (f)
+#endif
+         )
     {
       mouse_face_overwritten_p
 	|= (WINDOWP (w->contents)
@@ -32286,12 +32293,16 @@ expose_frame (struct frame *f, int x, int y, int w, int h)
 
   TRACE ((stderr, "expose_frame "));
 
-  /* No need to redraw if frame will be redrawn soon.  */
+#if !defined (HAVE_NS)
+  /* No need to redraw if frame will be redrawn soon except under NS
+     where the toolkit may have already modified the frame in
+     expectation of us redrawing it.  */
   if (FRAME_GARBAGED_P (f))
     {
       TRACE ((stderr, " garbaged\n"));
       return;
     }
+#endif
 
   /* If basic faces haven't been realized yet, there is no point in
      trying to redraw anything.  This can happen when we get an expose
-- 
2.19.1

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Aaron Jensen]

On November 23, 2018 at 10:17:58 AM, Alan Third
(alan@idiocy.org(mailto:alan@idiocy.org)) wrote:

> Final (hopefully) version of this patch attached.
>
> I guess there are still issues with it, but we’re running out of time
> to sort them for Emacs 26.2.

I’m using it, it seems to blank out occasionally, but no major
problems with it other than that.

Thanks,

Aaron

bug#32932: 26.2: Too many flickers with normal operations on macOS 10.13.6

[Zhang Haijun]

I can see blanks and then refreshing, sometimes just a blank retangle without refreshing.

Last version I used is emacs-26 branch on 2018-09-08 which has no such problem with same .emacs.

Xcode version: 9.2

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Aaron Jensen]

On Mon, Nov 26, 2018 at 8:20 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> I’m using it, it seems to blank out occasionally, but no major problems with it other than that.

I've definitely been seeing blank outs multiple times per day. I'm
curious if you have any other ideas to try, Alan.

I'm also sometimes noticing that some of my mode line segments get
"stuck" with the inactive face even when the window becomes active
again. It's possible that this is due to a bug in doom-modeline, but I
mention it here in case it's an Emacs issue.

Thanks,

Aaron

bug#32932: [PATCH v2] Fix more drawing bugs in NS port (bug#32932)

[Alan Third]

On Fri, Jan 25, 2019 at 06:02:27AM -0800, Aaron Jensen wrote:
> On Mon, Nov 26, 2018 at 8:20 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
> > I’m using it, it seems to blank out occasionally, but no major problems with it other than that.
> 
> I've definitely been seeing blank outs multiple times per day. I'm
> curious if you have any other ideas to try, Alan.

What I’ve noticed is that if something takes more than ~3 seconds,
then the active window tends to blank until whatever is running
finishes. I don’t think this is actually fixable using the current
scheme. Or I don’t have enough of an understanding of the problem to
fix it.

I’m feeling very tempted to go back and retry the drawing to an
off‐screen bitmap again. Last time I believe it had some performance
issues, and it didn’t work in Mojave, but maybe I’ll be able to work
around those issues.

> I'm also sometimes noticing that some of my mode line segments get
> "stuck" with the inactive face even when the window becomes active
> again. It's possible that this is due to a bug in doom-modeline, but I
> mention it here in case it's an Emacs issue.

I’ve not seen anything like that, but I use a very vanilla Emacs. I
wouldn’t rule out it being a bug in Emacs.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

Hi Robert,

In reference to our quick chat over on reddit here’s some information
on this work.

I have a branch on the Emacs git repo called scratch/ns/draw-to-bitmap
which contains my work on an alternative drawing scheme. It’s mostly
the same as it was before I introduced changes for Mojave, but with
the addition of drawing to a bitmap instead of directly to the frame.

It’s a little out of date and needs a merge from master to bring it up
to date.

The main bit of the code is around the method
createDrawingBufferWithRect in nsterm.m. It’s a simple bitmap and it’s
very slow to draw to the screen (drawRect:). I think that there are
things that can be done with layers and CGLayers, but I never managed
to work out how it’s supposed to work, or if it’s even plausible. I
don’t know if AppKit can draw directly to CGLayers.

The Mac port uses a similar design, but I didn’t think the actual code
was usable in the NS port, but I could be wrong.

Ultimately, if we get this working I’d be happy to use the same method
of drawing on pre‐Mojave macOS as GNUstep uses, so there are no
concerns with backwards compatibility. The biggest issue on that front
is that we can’t use clang features that aren’t also supported in GCC,
which means no ObjC ‘blocks’, which I think rules out using Metal.

Any questions, ask away, and thanks for offering to look at this, I
hope you have better luck than me!
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Robert Pluim]

>>>>> On Mon, 11 Nov 2019 18:16:22 +0000, Alan Third <alan@idiocy.org> said:
    Alan> The main bit of the code is around the method
    Alan> createDrawingBufferWithRect in nsterm.m. It’s a simple bitmap and it’s
    Alan> very slow to draw to the screen (drawRect:). I think that there are
    Alan> things that can be done with layers and CGLayers, but I never managed
    Alan> to work out how it’s supposed to work, or if it’s even plausible. I
    Alan> don’t know if AppKit can draw directly to CGLayers.

Question #1: How do you know itʼs slow? Iʼve been using it since this
morning, and it seems ok.

Robert

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On Tue, 12 Nov 2019, 13:28 Robert Pluim, <rpluim@gmail.com> wrote:

> >>>>> On Mon, 11 Nov 2019 18:16:22 +0000, Alan Third <alan@idiocy.org>
> said:
>     Alan> The main bit of the code is around the method
>     Alan> createDrawingBufferWithRect in nsterm.m. It’s a simple bitmap
> and it’s
>     Alan> very slow to draw to the screen (drawRect:). I think that there
> are
>     Alan> things that can be done with layers and CGLayers, but I never
> managed
>     Alan> to work out how it’s supposed to work, or if it’s even
> plausible. I
>     Alan> don’t know if AppKit can draw directly to CGLayers.
>
> Question #1: How do you know itʼs slow? Iʼve been using it since this
> morning, and it seems ok.
>

A couple of people tried it and found it slow. I run a fairly vanilla Emacs
and it looked ok to me, but if I full maximised it on my retina mac it was
visibly slower at things like scrolling than the current master branch.

[-- Attachment #2: Type: text/html, Size: 1603 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Tue, Nov 12, 2019 at 02:38:04PM +0000, Alan Third wrote:
> On Tue, 12 Nov 2019, 13:28 Robert Pluim, <rpluim@gmail.com> wrote:
> 
> > >>>>> On Mon, 11 Nov 2019 18:16:22 +0000, Alan Third <alan@idiocy.org> said:
> > > The main bit of the code is around the method
> > > createDrawingBufferWithRect in nsterm.m. It’s a simple bitmap
> > > and it’s very slow to draw to the screen (drawRect:). I think
> > > that there are things that can be done with layers and CGLayers,
> > > but I never managed to work out how it’s supposed to work, or if
> > > it’s even plausible. I don’t know if AppKit can draw directly to
> > > CGLayers.
> >
> > Question #1: How do you know itʼs slow? Iʼve been using it since this
> > morning, and it seems ok.
> >
> 
> A couple of people tried it and found it slow. I run a fairly vanilla Emacs
> and it looked ok to me, but if I full maximised it on my retina mac it was
> visibly slower at things like scrolling than the current master branch.

Hi Robert, I’d forgotten it was you who originally complained about
the performance.

I’ve been messing about with the branch and have been using this
benchmark nabbed from one of Eli’s posts on emacs devel:

    (defun scroll-up-benchmark ()
      (interactive)
      (let ((oldgc gcs-done)
            (oldtime (float-time)))
        (condition-case nil (while t (scroll-up) (redisplay))
          (error (message "GCs: %d Elapsed time: %f seconds"
                          (- gcs-done oldgc) (- (float-time) oldtime))))))

Maximised on my external 1920x1200 monitor the difference in that
benchmark with xdisp.c between drawing to a bitmap and using the
standard master branch is essentially nothing. Unfortunately using it
maximised on my laptop’s retina screen results in a difference of
something like 15 seconds (40 ‐> 55 ish).

On the other hand that’s a worst case scenario and in interactive use
it’s perfectly fine.

So we have a trade off here of slower performance, which may or may
not be an issue, against drawing anomalies. I’m beginning to feel it’s
probably better to just get rid of the drawing issues and live with
the performance hit. I know that for me the performance difference is
not going to be noticeable at all.

Do you have any thoughts on the matter?

(As an aside, if people using old hardware with old versions of macOS
find it slow we can easily set it to only use the backing buffer on
macOS 10.14+ and everyone else can use the same process as GNUstep,
which is the old pre‐Mojave drawing direct to the screen thing.)
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> Date: Sat, 25 Jan 2020 12:44:01 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: 32932@debbugs.gnu.org
> 
> So we have a trade off here of slower performance, which may or may
> not be an issue, against drawing anomalies. I’m beginning to feel it’s
> probably better to just get rid of the drawing issues and live with
> the performance hit. I know that for me the performance difference is
> not going to be noticeable at all.

I think your tendency is the correct way of handling this issue: first
be correct, then fast.

Thanks.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Robert Pluim]

>>>>> On Sat, 25 Jan 2020 15:37:41 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> Date: Sat, 25 Jan 2020 12:44:01 +0000
    >> From: Alan Third <alan@idiocy.org>
    >> Cc: 32932@debbugs.gnu.org
    >> 
    >> So we have a trade off here of slower performance, which may or may
    >> not be an issue, against drawing anomalies. I’m beginning to feel it’s
    >> probably better to just get rid of the drawing issues and live with
    >> the performance hit. I know that for me the performance difference is
    >> not going to be noticeable at all.

    Eli> I think your tendency is the correct way of handling this issue: first
    Eli> be correct, then fast.

The redraw problems have been starting to annoy me recently. Iʼll take
correctness over speed as well.

(Iʼve not found any inspired solution to the speed issue. I *have*
found various ways to kill Emacs, though :-) )

Robert

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Mon, Jan 27, 2020 at 12:06:32PM +0100, Robert Pluim wrote:
> >>>>> On Sat, 25 Jan 2020 15:37:41 +0200, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> Date: Sat, 25 Jan 2020 12:44:01 +0000
>     >> From: Alan Third <alan@idiocy.org>
>     >> Cc: 32932@debbugs.gnu.org
>     >> 
>     >> So we have a trade off here of slower performance, which may or may
>     >> not be an issue, against drawing anomalies. I’m beginning to feel it’s
>     >> probably better to just get rid of the drawing issues and live with
>     >> the performance hit. I know that for me the performance difference is
>     >> not going to be noticeable at all.
> 
>     Eli> I think your tendency is the correct way of handling this issue: first
>     Eli> be correct, then fast.
> 
> The redraw problems have been starting to annoy me recently. Iʼll take
> correctness over speed as well.

OK, so I think we’re agreed to switch to the scratch/ns/draw-to-bitmap
branch. Obviously we’re too late for Emacs 27, but should we wait
until the Emacs 27 release process has completed or just merge it into
master now?

> (Iʼve not found any inspired solution to the speed issue. I *have*
> found various ways to kill Emacs, though :-) )

Sounds familiar... ;)
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> Date: Mon, 27 Jan 2020 20:45:35 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 32932@debbugs.gnu.org
> 
> OK, so I think we’re agreed to switch to the scratch/ns/draw-to-bitmap
> branch. Obviously we’re too late for Emacs 27, but should we wait
> until the Emacs 27 release process has completed or just merge it into
> master now?

There's no need to wait with merging this to master.

Thanks.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Tue, Jan 28, 2020 at 05:21:06AM +0200, Eli Zaretskii wrote:
> > Date: Mon, 27 Jan 2020 20:45:35 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, 32932@debbugs.gnu.org
> > 
> > OK, so I think we’re agreed to switch to the scratch/ns/draw-to-bitmap
> > branch. Obviously we’re too late for Emacs 27, but should we wait
> > until the Emacs 27 release process has completed or just merge it into
> > master now?
> 
> There's no need to wait with merging this to master.

Done. Thanks all.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

I've tested this out and it's definitely noticeably slower. It
actually happens infrequently enough that I may actually be willing to
trade the speed for the correctness, but I'll use it for a while and
see how it goes.

Realistically, it looks like it may be the difference between being
able to scroll one line at a time reasonably and not, which is going
to hit spacemacs users and people that are used to scrolling in that
way hard. I know scrolling in that way is not the recommended
approach, but it's nicer experience than having the screen and the
point jump half way across the screen every time you need to see one
more line.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Tue, 28 Jan 2020 11:35:02 -0800
> 
> I know scrolling in that way is not the recommended approach, but
> it's nicer experience than having the screen and the point jump half
> way across the screen every time you need to see one more line.

Have you tried setting scroll-conservatively to 101?

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Tue, Jan 28, 2020 at 12:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> Have you tried setting scroll-conservatively to 101?

Yes, I use:

(setq scroll-margin 3
      scroll-preserve-screen-position t
      scroll-conservatively 101)

bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Tue, 28 Jan 2020 12:11:20 -0800
> Cc: 32932@debbugs.gnu.org
> 
> On Tue, Jan 28, 2020 at 12:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Have you tried setting scroll-conservatively to 101?
> 
> Yes, I use:
> 
> (setq scroll-margin 3
>       scroll-preserve-screen-position t
>       scroll-conservatively 101)

In that case, you should never see "the screen and the point jump half
way across the screen every time you need to see one more line."
Setting scroll-conservatively that way causes Emacs to scroll in
exactly one line when you want to see one more line.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Tue, Jan 28, 2020 at 12:21 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> In that case, you should never see "the screen and the point jump half
> way across the screen every time you need to see one more line."
> Setting scroll-conservatively that way causes Emacs to scroll in
> exactly one line when you want to see one more line.

Yes, that's exactly why I set it. I was describing why I set it
(specifically, the impact of my not setting it that leads me to set
it) and therefore why I'm in a situation where I am more impacted by
the scroll performance of the new patch.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

Hi Aaron, just as a test can you try disabling powerline?

On Tue, 28 Jan 2020, 19:53 Aaron Jensen, <aaronjensen@gmail.com> wrote:

> I've tested this out and it's definitely noticeably slower. It
> actually happens infrequently enough that I may actually be willing to
> trade the speed for the correctness, but I'll use it for a while and
> see how it goes.
>
> Realistically, it looks like it may be the difference between being
> able to scroll one line at a time reasonably and not, which is going
> to hit spacemacs users and people that are used to scrolling in that
> way hard. I know scrolling in that way is not the recommended
> approach, but it's nicer experience than having the screen and the
> point jump half way across the screen every time you need to see one
> more line.
>
> Aaron
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1142 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Wed, Jan 29, 2020 at 2:08 AM Alan Third <athird@googlemail.com> wrote:
>
> Hi Aaron, just as a test can you try disabling powerline?

Hi Alan, I don't use powerline, I use doom-modeline and disabling it
has no effect.

I actually have worse news. My original test was actually with an
unoptimized 27, as I forgot to actually run make (sigh). With 28, on
my 4k display, Emacs is unusable even with the modeline disabled. My
frame is only on about 3/5s of the screen, so it's not even taking up
the entire 4k. The latency on every paint is probably in the 200-400ms
range. I haven't measured it, but that's what it feels like.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Wed, Jan 29, 2020 at 08:32:25AM -0800, Aaron Jensen wrote:
> On Wed, Jan 29, 2020 at 2:08 AM Alan Third <athird@googlemail.com> wrote:
> >
> > Hi Aaron, just as a test can you try disabling powerline?
> 
> Hi Alan, I don't use powerline, I use doom-modeline and disabling it
> has no effect.
> 
> I actually have worse news. My original test was actually with an
> unoptimized 27, as I forgot to actually run make (sigh). With 28, on
> my 4k display, Emacs is unusable even with the modeline disabled. My
> frame is only on about 3/5s of the screen, so it's not even taking up
> the entire 4k. The latency on every paint is probably in the 200-400ms
> range. I haven't measured it, but that's what it feels like.

Really it shouldn’t be slow for updating relatively small areas, so if
every paint is that slow then we’ve got real trouble.

Do you use a transparent background in Emacs?

Can you try applying these three changes, and see if they make any
difference. I’d like you to try the first two both with and without
the third.

modified   src/nsterm.m
@@ -1141,7 +1141,7 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 
 #ifdef NS_IMPL_COCOA
   [NSGraphicsContext setCurrentContext:nil];
-  [view display];
+  //[view display];
 #else
   block_input ();
 
@@ -2853,7 +2853,7 @@ so some key presses (TAB) are swallowed by the system.  */
   ns_unfocus (f);
 
   /* as of 2006/11 or so this is now needed */
-  ns_redraw_scroll_bars (f);
+  //ns_redraw_scroll_bars (f);
   unblock_input ();
 }
 
@@ -8313,12 +8313,19 @@ - (void)drawRect: (NSRect)rect
     return;
 
 #ifdef NS_IMPL_COCOA
-  [drawingBuffer drawInRect:rect
-                   fromRect:rect
-                  operation:NSCompositingOperationSourceOver
-                   fraction:1
-             respectFlipped:NO
-                      hints:nil];
+  const NSRect *r;
+  NSInteger count;
+  int i;
+
+  [self getRectsBeingDrawn:&r count:&count];
+
+  for (i = 0 ; i < count ; i++)
+    [drawingBuffer drawInRect:r[i]
+                     fromRect:r[i]
+                    operation:NSCompositingOperationSourceOver
+                     fraction:1
+               respectFlipped:NO
+                        hints:nil];
 #else
   int x = NSMinX (rect), y = NSMinY (rect);
   int width = NSWidth (rect), height = NSHeight (rect);


-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Wed, Jan 29, 2020 at 12:04 PM Alan Third <alan@idiocy.org> wrote:
>
> On Wed, Jan 29, 2020 at 08:32:25AM -0800, Aaron Jensen wrote:
> > On Wed, Jan 29, 2020 at 2:08 AM Alan Third <athird@googlemail.com> wrote:
> > >
> > > Hi Aaron, just as a test can you try disabling powerline?
> >
> > Hi Alan, I don't use powerline, I use doom-modeline and disabling it
> > has no effect.
> >
> > I actually have worse news. My original test was actually with an
> > unoptimized 27, as I forgot to actually run make (sigh). With 28, on
> > my 4k display, Emacs is unusable even with the modeline disabled. My
> > frame is only on about 3/5s of the screen, so it's not even taking up
> > the entire 4k. The latency on every paint is probably in the 200-400ms
> > range. I haven't measured it, but that's what it feels like.
>
> Really it shouldn’t be slow for updating relatively small areas, so if
> every paint is that slow then we’ve got real trouble.
>
> Do you use a transparent background in Emacs?

No

>
> Can you try applying these three changes, and see if they make any
> difference. I’d like you to try the first two both with and without
> the third.

With regard to scrolling (full repaints) they make no difference,
which you likely suspected. These are my scroll-up-benchmark times for
one of my .org files:

Emacs 27: 2.6s

Emacs 28
No patches: 13.0s
First 2: 13.2s
All 3: 13.8s

In terms of just repainting when I move the point, applying the first
2 patches made a noticeable difference. It is still sluggish compared
to 27. I'm not sure I can tell a difference with the 3rd patch applied
as well. It seems similar or maybe slightly faster.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Wed, Jan 29, 2020 at 05:40:52PM -0800, Aaron Jensen wrote:
> On Wed, Jan 29, 2020 at 12:04 PM Alan Third <alan@idiocy.org> wrote:
> >
> > Can you try applying these three changes, and see if they make any
> > difference. I’d like you to try the first two both with and without
> > the third.
> 
> With regard to scrolling (full repaints) they make no difference,
> which you likely suspected. These are my scroll-up-benchmark times for
> one of my .org files:
> 
> Emacs 27: 2.6s
> 
> Emacs 28
> No patches: 13.0s
> First 2: 13.2s
> All 3: 13.8s
> 
> In terms of just repainting when I move the point, applying the first
> 2 patches made a noticeable difference. It is still sluggish compared
> to 27. I'm not sure I can tell a difference with the 3rd patch applied
> as well. It seems similar or maybe slightly faster.

Thanks for testing.

I see three probable places which might be making it very slow:

The obvious one is copying the bitmap to the screen in drawRect:. I
don’t think there’s any way around that other than working out how to
make better use of hardware acceleration with something like Metal.

For scrolling the actual process of copying a chunk of the offscreen
bitmap in copyRect: may be slow. Again we could probably improve that with some
sort of hardware acceleration.

The third place is getting the bitmap’s graphics context in
focusOnDrawingBuffer. I _know_ this is slow, and it’s possible,
probable even, that spacemacs causes it to happen far more often than
on vanilla Emacs.

It may be that we need to fix all of these, but is it possible for you
to run a profile and find out what’s using up the most time?

I’m wondering if it would be worth my time going onto, say, the Emacs
reddit and seeing if I can drum up interest from Mac developers. There
surely have to be SOME out there who use Emacs...
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Thu, Jan 30, 2020 at 11:11 AM Alan Third <alan@idiocy.org> wrote:
>
> It may be that we need to fix all of these, but is it possible for you
> to run a profile and find out what’s using up the most time?

I'd be happy to, but I don't know how to do that (assuming it's not
profiler.el you're referring to).

> I’m wondering if it would be worth my time going onto, say, the Emacs
> reddit and seeing if I can drum up interest from Mac developers. There
> surely have to be SOME out there who use Emacs...

Possibly, yeah. A hardware accelerated version would be great, though
I remember you saying something about not being able to use Metal, is
that because of licensing concerns with the tooling?

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 239 bytes --]

Thank you for working on this.

FWIW, I think a Reddit post sounds like a great idea. We have a large user
base, and it can only help to experiment with different ways of getting
more people involved in Emacs.

Best regards,
Stefan Kangas

[-- Attachment #2: Type: text/html, Size: 667 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Robert Pluim]

>>>>> On Thu, 30 Jan 2020 12:07:18 -0800, Aaron Jensen <aaronjensen@gmail.com> said:

    Aaron> On Thu, Jan 30, 2020 at 11:11 AM Alan Third <alan@idiocy.org> wrote:
    >> 
    >> It may be that we need to fix all of these, but is it possible for you
    >> to run a profile and find out what’s using up the most time?

    Aaron> I'd be happy to, but I don't know how to do that (assuming it's not
    Aaron> profiler.el you're referring to).

My results mirror Aaron's. Alan, what kind of profiling would you like
to see? (I donʼt think perf runs on macOS, but I could be wrong).

Robert

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Fri, Jan 31, 2020 at 03:57:09PM +0100, Robert Pluim wrote:
> >>>>> On Thu, 30 Jan 2020 12:07:18 -0800, Aaron Jensen <aaronjensen@gmail.com> said:
> 
>     Aaron> On Thu, Jan 30, 2020 at 11:11 AM Alan Third <alan@idiocy.org> wrote:
>     >> 
>     >> It may be that we need to fix all of these, but is it possible for you
>     >> to run a profile and find out what’s using up the most time?
> 
>     Aaron> I'd be happy to, but I don't know how to do that (assuming it's not
>     Aaron> profiler.el you're referring to).
> 
> My results mirror Aaron's. Alan, what kind of profiling would you like
> to see? (I donʼt think perf runs on macOS, but I could be wrong).

I’m thinking of time spent in functions during, perhaps the scroll
benchark, or just general use. I know it can be done through xcode and
I think gperftools perhaps works on macOS.

Alternatively I may be able to do it. Is it just a matter of grabbing
the spacemacs config and using it, or do I need to do anything
further?
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Fri, Jan 31, 2020 at 12:23 PM Alan Third <alan@idiocy.org> wrote:
>
> I’m thinking of time spent in functions during, perhaps the scroll
> benchark, or just general use. I know it can be done through xcode and
> I think gperftools perhaps works on macOS.
>
> Alternatively I may be able to do it. Is it just a matter of grabbing
> the spacemacs config and using it, or do I need to do anything
> further?

I don't actually use spacemacs anymore, I have my own config, but I
believe the slowness is reproducible in `emacs -Q` on my 4k monitor. I
don't have that machine here, but I can verify it when I get home. If
it is specific to my config, I can share it with you.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Mattias Engdegård]

Merely moving the cursor has become sluggish here, without even scrolling. Racing down the screen at the left margin, Emacs often doesn't even keep up with keyboard repeat; it keeps going a few lines after C-n has been released.

The occasional screen blanking was annoying, but somehow this feels even less satisfactory --- I'm running with the merge reverted for now.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Fri, Jan 31, 2020 at 12:26 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Fri, Jan 31, 2020 at 12:23 PM Alan Third <alan@idiocy.org> wrote:
> >
> > I’m thinking of time spent in functions during, perhaps the scroll
> > benchark, or just general use. I know it can be done through xcode and
> > I think gperftools perhaps works on macOS.
> >
> > Alternatively I may be able to do it. Is it just a matter of grabbing
> > the spacemacs config and using it, or do I need to do anything
> > further?
>
> I don't actually use spacemacs anymore, I have my own config, but I
> believe the slowness is reproducible in `emacs -Q` on my 4k monitor. I
> don't have that machine here, but I can verify it when I get home. If
> it is specific to my config, I can share it with you.

Hi Alan,

I just confirmed that it happens with emacs -Q. It's directly
proportional to the size of the window. The default window size is
pretty fast, but even a nearly blank buffer that's full screen lags
when the point moves.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Fri, Jan 31, 2020 at 05:26:21PM -0800, Aaron Jensen wrote:
> On Fri, Jan 31, 2020 at 12:26 PM Aaron Jensen <aaronjensen@gmail.com> wrote:
> >
> > On Fri, Jan 31, 2020 at 12:23 PM Alan Third <alan@idiocy.org> wrote:
> > >
> > > I’m thinking of time spent in functions during, perhaps the scroll
> > > benchark, or just general use. I know it can be done through xcode and
> > > I think gperftools perhaps works on macOS.
> > >
> > > Alternatively I may be able to do it. Is it just a matter of grabbing
> > > the spacemacs config and using it, or do I need to do anything
> > > further?
> >
> > I don't actually use spacemacs anymore, I have my own config, but I
> > believe the slowness is reproducible in `emacs -Q` on my 4k monitor. I
> > don't have that machine here, but I can verify it when I get home. If
> > it is specific to my config, I can share it with you.
> 
> Hi Alan,
> 
> I just confirmed that it happens with emacs -Q. It's directly
> proportional to the size of the window. The default window size is
> pretty fast, but even a nearly blank buffer that's full screen lags
> when the point moves.

Thanks. I finally got my xcode install working again and tried just
profiling various actions and I think I know what’s going on.

NSBitmapImageRep is mutable, however it’s built on a CGImage or
something that isn’t, so every time you want to edit an
NSBitmapImageRep it has to copy the entire thing. This is why this
little bit of code to grab the bitmap’s graphics context

    [NSGraphicsContext
      graphicsContextWithBitmapImageRep:drawingBuffer]

is so damn slow and it gets slower as the screensize increases.

I’m now stumped because I can’t actually find any image type in the
documentation that isn’t immutable. I’m sure there must be something.
The Mac port appears to be using IOSurfaces, but as far as I can tell
they can be changed underneath you so aren’t much use for just
updating little bits of the Emacs frame at a time. I must be
misunderstanding something.

-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Sat, Feb 1, 2020 at 6:22 AM Alan Third <alan@idiocy.org> wrote:
>
> I’m now stumped because I can’t actually find any image type in the
> documentation that isn’t immutable. I’m sure there must be something.
> The Mac port appears to be using IOSurfaces, but as far as I can tell
> they can be changed underneath you so aren’t much use for just
> updating little bits of the Emacs frame at a time. I must be
> misunderstanding something.

I know nothing, but have you looked into
https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_layers/dq_layers.html
?

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Sat, Feb 01, 2020 at 08:29:10AM -0800, Aaron Jensen wrote:
> On Sat, Feb 1, 2020 at 6:22 AM Alan Third <alan@idiocy.org> wrote:
> >
> > I’m now stumped because I can’t actually find any image type in the
> > documentation that isn’t immutable. I’m sure there must be something.
> > The Mac port appears to be using IOSurfaces, but as far as I can tell
> > they can be changed underneath you so aren’t much use for just
> > updating little bits of the Emacs frame at a time. I must be
> > misunderstanding something.
> 
> I know nothing, but have you looked into
> https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_layers/dq_layers.html
> ?

Can you try the attached patch? It looks like it’s faster here, but I
can’t really tell.
-- 
Alan Third

[-- Attachment #2: 0001-Use-CGLayer-instead-of-NSBitmapImageRep-bug-32932.patch --]
[-- Type: text/plain, Size: 5704 bytes --]

From ad2feeba4284ce7ef7518781c26bd2a98389372a Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sat, 1 Feb 2020 21:17:29 +0000
Subject: [PATCH] Use CGLayer instead of NSBitmapImageRep (bug#32932)

---
 src/nsterm.h |  2 +-
 src/nsterm.m | 67 ++++++++++++++++++++++------------------------------
 2 files changed, 29 insertions(+), 40 deletions(-)

diff --git a/src/nsterm.h b/src/nsterm.h
index 980ca534cf..fbcd29be12 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -418,7 +418,7 @@ #define NSTRACE_UNSILENCE()
    NSWindow *nonfs_window;
    BOOL fs_is_native;
 #ifdef NS_IMPL_COCOA
-   NSBitmapImageRep *drawingBuffer;
+   CGLayerRef drawingBuffer;
 #endif
 @public
    struct frame *emacsframe;
diff --git a/src/nsterm.m b/src/nsterm.m
index 9d427b9b38..94662a24fe 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1141,7 +1141,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 
 #ifdef NS_IMPL_COCOA
   [NSGraphicsContext setCurrentContext:nil];
-  [view display];
 #else
   block_input ();
 
@@ -2853,7 +2852,9 @@ so some key presses (TAB) are swallowed by the system.  */
   ns_unfocus (f);
 
   /* as of 2006/11 or so this is now needed */
-  ns_redraw_scroll_bars (f);
+  /* FIXME: I don't see any reason for this and removing it makes no
+     difference here.  Do we need it for GNUstep?  */
+  //ns_redraw_scroll_bars (f);
   unblock_input ();
 }
 
@@ -3169,18 +3170,6 @@ so some key presses (TAB) are swallowed by the system.  */
 
       NSTRACE_RECT ("fromRect", fromRect);
 
-      /* Because we're drawing into an offscreen buffer which isn't
-         flipped, the images come out upside down.  To work around it
-         we need to do some fancy transforms.  */
-      {
-        NSAffineTransform *transform = [NSAffineTransform transform];
-        [transform translateXBy:0 yBy:NSMaxY(imageRect)];
-        [transform scaleXBy:1 yBy:-1];
-        [transform concat];
-
-        imageRect.origin.y = 0;
-      }
-
       [img drawInRect: imageRect
              fromRect: fromRect
             operation: NSCompositingOperationSourceOver
@@ -3938,11 +3927,6 @@ Function modeled after x_draw_glyph_string_box ().
 
       NSAffineTransform *doTransform = [NSAffineTransform transform];
 
-      /* We have to flip the image around the X axis as the offscreen
-         bitmap we're drawing to is flipped.  */
-      [doTransform scaleXBy:1 yBy:-1];
-      [doTransform translateXBy:0 yBy:-[img size].height];
-
       /* ImageMagick images don't have transforms.  */
       if (img->transform)
         [doTransform appendTransform:img->transform];
@@ -4838,7 +4822,7 @@ in certain situations (rapid incoming events).
   if (NILP (window->vertical_scroll_bar))
     {
       if (width > 0 && height > 0)
-	ns_clear_frame_area (f, left, top, width, height);
+        ns_clear_frame_area (f, left, top, width, height);
 
       bar = [[EmacsScroller alloc] initFrame: r window: win];
       wset_vertical_scroll_bar (window, make_mint_ptr (bar));
@@ -8239,10 +8223,15 @@ - (void)createDrawingBufferWithRect:(NSRect)rect
      retain the old method of drawing direct to the EmacsView.  */
 {
 #ifdef NS_IMPL_COCOA
+  NSGraphicsContext *screen;
+
   if (drawingBuffer != nil)
-    [drawingBuffer release];
+    CGLayerRelease (drawingBuffer);
 
-  drawingBuffer = [[self bitmapImageRepForCachingDisplayInRect:rect] retain];
+  screen = [NSGraphicsContext graphicsContextWithBitmapImageRep:
+                    [self bitmapImageRepForCachingDisplayInRect:rect]];
+
+  drawingBuffer = CGLayerCreateWithContext ([screen CGContext], rect.size, nil);
 #endif
 }
 
@@ -8250,11 +8239,12 @@ - (void)createDrawingBufferWithRect:(NSRect)rect
 #ifdef NS_IMPL_COCOA
 - (void)focusOnDrawingBuffer
 {
-  /* Creating the graphics context each time is very slow, but it
-     doesn't seem possible to cache and reuse it.  */
-  [NSGraphicsContext
-    setCurrentContext:
-      [NSGraphicsContext graphicsContextWithBitmapImageRep:drawingBuffer]];
+  NSGraphicsContext *buf =
+    [NSGraphicsContext
+        graphicsContextWithCGContext:CGLayerGetContext (drawingBuffer)
+                             flipped:YES];
+
+  [NSGraphicsContext setCurrentContext:buf];
 }
 
 
@@ -8284,13 +8274,16 @@ - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect
   NSTRACE_RECT ("Destination", dstRect);
 
 #ifdef NS_IMPL_COCOA
-  [drawingBuffer drawInRect:dstRect
-                   fromRect:srcRect
-                  operation:NSCompositingOperationCopy
-                   fraction:1.0
-             respectFlipped:NO
-                      hints:nil];
+  CGPoint offset = CGPointMake (NSMinX (dstRect) - NSMinX (srcRect),
+                                NSMinY (dstRect) - NSMinY (srcRect));
+  [[NSGraphicsContext currentContext] saveGraphicsState];
 
+  NSRectClip (dstRect);
+
+  CGContextDrawLayerAtPoint ([[NSGraphicsContext currentContext] CGContext],
+                             offset, drawingBuffer);
+
+  [[NSGraphicsContext currentContext] restoreGraphicsState];
   [self setNeedsDisplayInRect:dstRect];
 #else
   hide_bell();              // Ensure the bell image isn't scrolled.
@@ -8313,12 +8306,8 @@ - (void)drawRect: (NSRect)rect
     return;
 
 #ifdef NS_IMPL_COCOA
-  [drawingBuffer drawInRect:rect
-                   fromRect:rect
-                  operation:NSCompositingOperationSourceOver
-                   fraction:1
-             respectFlipped:NO
-                      hints:nil];
+  CGContextRef ctx = [[NSGraphicsContext currentContext] CGContext];
+  CGContextDrawLayerAtPoint (ctx, CGPointZero, drawingBuffer);
 #else
   int x = NSMinX (rect), y = NSMinY (rect);
   int width = NSWidth (rect), height = NSHeight (rect);
-- 
2.24.0

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Sat, Feb 1, 2020 at 1:20 PM Alan Third <alan@idiocy.org> wrote:
>
> Can you try the attached patch? It looks like it’s faster here, but I
> can’t really tell.

Moving the point is definitely faster. It's still slower as the window
gets larger, but that's not really new behavior (27 is that way too).
Scrolling speed is still unbearable, however.

I don't know if you've seen or read this, but I came across this just
now, but haven't looked too closely:

https://books.google.com/books?id=QyFta827Y0gC&pg=PA85&lpg=PA85&dq=quartz+double+buffering&source=bl&ots=seLTG6QxV9&sig=ACfU3U35VUiIowXtgJsaky73k5aAPSNRlw&hl=en&ppis=_c&sa=X&ved=2ahUKEwj_uOzZt7HnAhXQrJ4KHR8qDo0Q6AEwAXoECAwQAQ#v=onepage&q=quartz%20double%20buffering&f=false

I'm curious if there's some nugget in there that might lead to a way
to do normal double buffering instead of this approach, since:

"Buffering. Although you can use layers for this purpose, you
shouldn’t need to because the Quartz Compositor makes buffering on
your part unnecessary. If you must draw to a buffer, use a layer
instead of a bitmap graphics context." via
https://books.google.com/books?id=QyFta827Y0gC&pg=PA85&lpg=PA85&dq=quartz+double+buffering&source=bl&ots=seLTG6QxV9&sig=ACfU3U35VUiIowXtgJsaky73k5aAPSNRlw&hl=en&ppis=_c&sa=X&ved=2ahUKEwj_uOzZt7HnAhXQrJ4KHR8qDo0Q6AEwAXoECAwQAQ#v=onepage&q=quartz%20double%20buffering&f=false

bug#32932: 27.0.50; render bugs on macOS Mojave

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

> Can you try the attached patch? It looks like it’s faster here, but I can’t really tell.

Cures the speed problems for me, but the text became fuzzy (MacBook Pro Retina).
Two Emacs instances, without and with the patch:



Thank you very much for working on this!


[-- Attachment #2.1: Type: text/html, Size: 856 bytes --]

[-- Attachment #2.2: Skärmavbild 2020-02-02 kl. 13.25.55.png --]
[-- Type: image/png, Size: 44826 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sat, Feb 01, 2020 at 03:05:45PM -0800, Aaron Jensen wrote:
> On Sat, Feb 1, 2020 at 1:20 PM Alan Third <alan@idiocy.org> wrote:
> >
> > Can you try the attached patch? It looks like it’s faster here, but I
> > can’t really tell.
> 
> Moving the point is definitely faster. It's still slower as the window
> gets larger, but that's not really new behavior (27 is that way too).
> Scrolling speed is still unbearable, however.

Out of interest, is the mac port fast under the same conditions? Here
their performance seems to be almost identical with the mac port only
fractionally faster, and their performance scales similarly with frame
size.

> I don't know if you've seen or read this, but I came across this just
> now, but haven't looked too closely:
> 
> https://books.google.com/books?id=QyFta827Y0gC&pg=PA85&lpg=PA85&dq=quartz+double+buffering&source=bl&ots=seLTG6QxV9&sig=ACfU3U35VUiIowXtgJsaky73k5aAPSNRlw&hl=en&ppis=_c&sa=X&ved=2ahUKEwj_uOzZt7HnAhXQrJ4KHR8qDo0Q6AEwAXoECAwQAQ#v=onepage&q=quartz%20double%20buffering&f=false
> 
> I'm curious if there's some nugget in there that might lead to a way
> to do normal double buffering instead of this approach, since:
> 
> "Buffering. Although you can use layers for this purpose, you
> shouldn’t need to because the Quartz Compositor makes buffering on
> your part unnecessary. If you must draw to a buffer, use a layer
> instead of a bitmap graphics context." via
> https://books.google.com/books?id=QyFta827Y0gC&pg=PA85&lpg=PA85&dq=quartz+double+buffering&source=bl&ots=seLTG6QxV9&sig=ACfU3U35VUiIowXtgJsaky73k5aAPSNRlw&hl=en&ppis=_c&sa=X&ved=2ahUKEwj_uOzZt7HnAhXQrJ4KHR8qDo0Q6AEwAXoECAwQAQ#v=onepage&q=quartz%20double%20buffering&f=false

I think that second URL is wrong, but I’ve read that quote before.
Normal double buffering is simply drawing like we do on Emacs 27.
There are plenty of places in the documentation that push you towards
just drawing when you want to recreate part of the screen, however as
we know Emacs redisplay isn’t really amenable to that approach.

It’s annoying, because Emacs 27 scrolls about 5x faster than the
buffer method.

-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sun, Feb 02, 2020 at 01:31:24PM +0100, Mattias Engdegård wrote:
> > Can you try the attached patch? It looks like it’s faster here, but I can’t really tell.
> 
> Cures the speed problems for me, but the text became fuzzy (MacBook Pro Retina).
> Two Emacs instances, without and with the patch:

Thanks for testing it. I think the fuzzyness is just the pre‐mojave
anti‐aliasing coming back. I don’t know why.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Sun, Feb 2, 2020 at 5:42 AM Alan Third <alan@idiocy.org> wrote:
>
> Out of interest, is the mac port fast under the same conditions? Here
> their performance seems to be almost identical with the mac port only
> fractionally faster, and their performance scales similarly with frame
> size.

For scrolling/full repaints the mac port is significantly faster,
similar to repaint speed of cursor moves. With the patch, Emacs 28's
full repaint when taking about 3/5s of my screen takes about 400ms
whereas it's about 16.7ms (60fps) with mac port. Emacs 27 seems to
paint even faster than that.

Also, I misstated my screen's specs, it's not a 4k display it's a 5k2k
screen with a native resolution of 5120 x 2160. So, it's as tall as
4k, but wider. I don't generally use emacs full width, however.

On Sun, Feb 2, 2020 at 5:46 AM Alan Third <alan@idiocy.org> wrote:
>
> > Cures the speed problems for me, but the text became fuzzy (MacBook Pro Retina).
> > Two Emacs instances, without and with the patch:
>
> Thanks for testing it. I think the fuzzyness is just the pre‐mojave
> anti‐aliasing coming back. I don’t know why.

Ah, good eye. Mine is blurry too. Could it be creating a layer that is
the size of hidpi scaled window but not the actual pixel size of the
window? That would explain the blur if it was then drawn to a larger
pixel-wise window.

> I think that second URL is wrong, but I’ve read that quote before.
> Normal double buffering is simply drawing like we do on Emacs 27.
> There are plenty of places in the documentation that push you towards
> just drawing when you want to recreate part of the screen, however as
> we know Emacs redisplay isn’t really amenable to that approach.

Do you know the cause of the glitching? Or is that still unclear? I
wonder if we could take some time to walk through it together, maybe
something will stand out?

Thanks,

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 2300 bytes --]

On Sun, Feb 02, 2020 at 08:49:44AM -0800, Aaron Jensen wrote:
> On Sun, Feb 2, 2020 at 5:42 AM Alan Third <alan@idiocy.org> wrote:
> >
> > Out of interest, is the mac port fast under the same conditions? Here
> > their performance seems to be almost identical with the mac port only
> > fractionally faster, and their performance scales similarly with frame
> > size.
> 
> For scrolling/full repaints the mac port is significantly faster,
> similar to repaint speed of cursor moves. With the patch, Emacs 28's
> full repaint when taking about 3/5s of my screen takes about 400ms
> whereas it's about 16.7ms (60fps) with mac port. Emacs 27 seems to
> paint even faster than that.

Amazingly the attached patch is faster than the mac port on my machine
(13" retina macbook pro) in the scroll test.

I can’t see that holding for your screen, though.

> On Sun, Feb 2, 2020 at 5:46 AM Alan Third <alan@idiocy.org> wrote:
> >
> > > Cures the speed problems for me, but the text became fuzzy (MacBook Pro Retina).
> > > Two Emacs instances, without and with the patch:
> >
> > Thanks for testing it. I think the fuzzyness is just the pre‐mojave
> > anti‐aliasing coming back. I don’t know why.
> 
> Ah, good eye. Mine is blurry too. Could it be creating a layer that is
> the size of hidpi scaled window but not the actual pixel size of the
> window? That would explain the blur if it was then drawn to a larger
> pixel-wise window.

So turns out you need to do some fancy‐pants manoeuvres to scale
CGLayers correctly. They also appear to draw faster when correctly
scaled, presumably because it’s not having to scale everything while
drawing to the screen.

> > I think that second URL is wrong, but I’ve read that quote before.
> > Normal double buffering is simply drawing like we do on Emacs 27.
> > There are plenty of places in the documentation that push you towards
> > just drawing when you want to recreate part of the screen, however as
> > we know Emacs redisplay isn’t really amenable to that approach.
> 
> Do you know the cause of the glitching? Or is that still unclear? I
> wonder if we could take some time to walk through it together, maybe
> something will stand out?

I know exactly what’s causing the glitching, but I’ll come back to
this tomorrow.
-- 
Alan Third

[-- Attachment #2: v2-0001-Use-CGLayer-instead-of-NSBitmapImageRep-bug-32932.patch --]
[-- Type: text/plain, Size: 7756 bytes --]

From 90e329cb6956bd40e927d74576ca8b5f48e5a72e Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sat, 1 Feb 2020 21:17:29 +0000
Subject: [PATCH v2] Use CGLayer instead of NSBitmapImageRep (bug#32932)

---
 src/nsterm.h |  4 +--
 src/nsterm.m | 89 +++++++++++++++++++++++++++-------------------------
 2 files changed, 48 insertions(+), 45 deletions(-)

diff --git a/src/nsterm.h b/src/nsterm.h
index 980ca534cf..eefa4d706d 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -418,7 +418,7 @@ #define NSTRACE_UNSILENCE()
    NSWindow *nonfs_window;
    BOOL fs_is_native;
 #ifdef NS_IMPL_COCOA
-   NSBitmapImageRep *drawingBuffer;
+   CGLayerRef drawingBuffer;
 #endif
 @public
    struct frame *emacsframe;
@@ -464,7 +464,7 @@ #define NSTRACE_UNSILENCE()
 - (void)focusOnDrawingBuffer;
 #endif
 - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect;
-- (void)createDrawingBufferWithRect:(NSRect)rect;
+- (void)createDrawingBuffer;
 
 /* Non-notification versions of NSView methods. Used for direct calls.  */
 - (void)windowWillEnterFullScreen;
diff --git a/src/nsterm.m b/src/nsterm.m
index 9d427b9b38..3576b851a5 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1141,7 +1141,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 
 #ifdef NS_IMPL_COCOA
   [NSGraphicsContext setCurrentContext:nil];
-  [view display];
 #else
   block_input ();
 
@@ -2853,7 +2852,9 @@ so some key presses (TAB) are swallowed by the system.  */
   ns_unfocus (f);
 
   /* as of 2006/11 or so this is now needed */
-  ns_redraw_scroll_bars (f);
+  /* FIXME: I don't see any reason for this and removing it makes no
+     difference here.  Do we need it for GNUstep?  */
+  //ns_redraw_scroll_bars (f);
   unblock_input ();
 }
 
@@ -3169,18 +3170,6 @@ so some key presses (TAB) are swallowed by the system.  */
 
       NSTRACE_RECT ("fromRect", fromRect);
 
-      /* Because we're drawing into an offscreen buffer which isn't
-         flipped, the images come out upside down.  To work around it
-         we need to do some fancy transforms.  */
-      {
-        NSAffineTransform *transform = [NSAffineTransform transform];
-        [transform translateXBy:0 yBy:NSMaxY(imageRect)];
-        [transform scaleXBy:1 yBy:-1];
-        [transform concat];
-
-        imageRect.origin.y = 0;
-      }
-
       [img drawInRect: imageRect
              fromRect: fromRect
             operation: NSCompositingOperationSourceOver
@@ -3938,11 +3927,6 @@ Function modeled after x_draw_glyph_string_box ().
 
       NSAffineTransform *doTransform = [NSAffineTransform transform];
 
-      /* We have to flip the image around the X axis as the offscreen
-         bitmap we're drawing to is flipped.  */
-      [doTransform scaleXBy:1 yBy:-1];
-      [doTransform translateXBy:0 yBy:-[img size].height];
-
       /* ImageMagick images don't have transforms.  */
       if (img->transform)
         [doTransform appendTransform:img->transform];
@@ -4838,7 +4822,7 @@ in certain situations (rapid incoming events).
   if (NILP (window->vertical_scroll_bar))
     {
       if (width > 0 && height > 0)
-	ns_clear_frame_area (f, left, top, width, height);
+        ns_clear_frame_area (f, left, top, width, height);
 
       bar = [[EmacsScroller alloc] initFrame: r window: win];
       wset_vertical_scroll_bar (window, make_mint_ptr (bar));
@@ -7104,7 +7088,7 @@ - (void) updateFrameSize: (BOOL) delay
          from non-native fullscreen, in other circumstances it appears
          to be a noop.  (bug#28872) */
       wr = NSMakeRect (0, 0, neww, newh);
-      [self createDrawingBufferWithRect:wr];
+      [self createDrawingBuffer];
       [view setFrame: wr];
 
       // To do: consider using [NSNotificationCenter postNotificationName:].
@@ -7444,7 +7428,7 @@ - (instancetype) initFrameFromEmacs: (struct frame *)f
   maximizing_resize = NO;
 #endif
 
-  [self createDrawingBufferWithRect:r];
+  [self createDrawingBuffer];
 
   win = [[EmacsWindow alloc]
             initWithContentRect: r
@@ -8229,7 +8213,7 @@ - (instancetype)toggleToolbar: (id)sender
 }
 
 
-- (void)createDrawingBufferWithRect:(NSRect)rect
+- (void)createDrawingBuffer
   /* Create and store a new NSBitmapImageRep for Emacs to draw
      into.
 
@@ -8239,10 +8223,24 @@ - (void)createDrawingBufferWithRect:(NSRect)rect
      retain the old method of drawing direct to the EmacsView.  */
 {
 #ifdef NS_IMPL_COCOA
+  NSGraphicsContext *screen;
+  CGFloat scale = [[self window] backingScaleFactor];
+  NSRect frame = [self frame];
+  NSSize size = frame.size;
+
   if (drawingBuffer != nil)
-    [drawingBuffer release];
+    CGLayerRelease (drawingBuffer);
+
+  size.width *= scale;
+  size.height *= scale;
+
+  screen = [NSGraphicsContext graphicsContextWithBitmapImageRep:
+                    [self bitmapImageRepForCachingDisplayInRect:frame]];
+
+  drawingBuffer = CGLayerCreateWithContext ([screen CGContext], size, nil);
+  CGContextRef cgctx = CGLayerGetContext (drawingBuffer);
+  CGContextScaleCTM(cgctx, scale, scale);
 
-  drawingBuffer = [[self bitmapImageRepForCachingDisplayInRect:rect] retain];
 #endif
 }
 
@@ -8250,11 +8248,15 @@ - (void)createDrawingBufferWithRect:(NSRect)rect
 #ifdef NS_IMPL_COCOA
 - (void)focusOnDrawingBuffer
 {
-  /* Creating the graphics context each time is very slow, but it
-     doesn't seem possible to cache and reuse it.  */
-  [NSGraphicsContext
-    setCurrentContext:
-      [NSGraphicsContext graphicsContextWithBitmapImageRep:drawingBuffer]];
+  NSGraphicsContext *buf;
+  CGContextRef cgctx = CGLayerGetContext (drawingBuffer);
+  CGFloat scale = [[self window] backingScaleFactor];
+
+  buf =
+    [NSGraphicsContext
+        graphicsContextWithCGContext:cgctx flipped:YES];
+
+  [NSGraphicsContext setCurrentContext:buf];
 }
 
 
@@ -8269,7 +8271,7 @@ - (void)windowDidChangeBackingProperties:(NSNotification *)notification
    if (old != new)
      {
        NSRect frame = [self frame];
-       [self createDrawingBufferWithRect:frame];
+       [self createDrawingBuffer];
        ns_clear_frame (emacsframe);
        expose_frame (emacsframe, 0, 0, NSWidth (frame), NSHeight (frame));
      }
@@ -8284,13 +8286,18 @@ - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect
   NSTRACE_RECT ("Destination", dstRect);
 
 #ifdef NS_IMPL_COCOA
-  [drawingBuffer drawInRect:dstRect
-                   fromRect:srcRect
-                  operation:NSCompositingOperationCopy
-                   fraction:1.0
-             respectFlipped:NO
-                      hints:nil];
+  CGRect offsetRect = CGRectMake (NSMinX (dstRect) - NSMinX (srcRect),
+                                  NSMinY (dstRect) - NSMinY (srcRect),
+                                  NSWidth ([self frame]),
+                                  NSHeight ([self frame]));
+  [[NSGraphicsContext currentContext] saveGraphicsState];
+
+  NSRectClip (dstRect);
 
+  CGContextDrawLayerInRect ([[NSGraphicsContext currentContext] CGContext],
+                             offsetRect, drawingBuffer);
+
+  [[NSGraphicsContext currentContext] restoreGraphicsState];
   [self setNeedsDisplayInRect:dstRect];
 #else
   hide_bell();              // Ensure the bell image isn't scrolled.
@@ -8313,12 +8320,8 @@ - (void)drawRect: (NSRect)rect
     return;
 
 #ifdef NS_IMPL_COCOA
-  [drawingBuffer drawInRect:rect
-                   fromRect:rect
-                  operation:NSCompositingOperationSourceOver
-                   fraction:1
-             respectFlipped:NO
-                      hints:nil];
+  CGContextRef ctx = [[NSGraphicsContext currentContext] CGContext];
+  CGContextDrawLayerInRect (ctx, [self frame], drawingBuffer);
 #else
   int x = NSMinX (rect), y = NSMinY (rect);
   int width = NSWidth (rect), height = NSHeight (rect);
-- 
2.24.0

bug#32932: 27.0.50; render bugs on macOS Mojave

[Mattias Engdegård]

2 feb. 2020 kl. 23.30 skrev Alan Third <alan@idiocy.org>:

> So turns out you need to do some fancy‐pants manoeuvres to scale
> CGLayers correctly. They also appear to draw faster when correctly
> scaled, presumably because it’s not having to scale everything while
> drawing to the screen.

Very nice, text is back in focus and the speed seems fine.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Sun, Feb 2, 2020 at 2:30 PM Alan Third <alan@idiocy.org> wrote:
>
> On Sun, Feb 02, 2020 at 08:49:44AM -0800, Aaron Jensen wrote:
> > On Sun, Feb 2, 2020 at 5:42 AM Alan Third <alan@idiocy.org> wrote:
> > >
> > > Out of interest, is the mac port fast under the same conditions? Here
> > > their performance seems to be almost identical with the mac port only
> > > fractionally faster, and their performance scales similarly with frame
> > > size.
> >
> > For scrolling/full repaints the mac port is significantly faster,
> > similar to repaint speed of cursor moves. With the patch, Emacs 28's
> > full repaint when taking about 3/5s of my screen takes about 400ms
> > whereas it's about 16.7ms (60fps) with mac port. Emacs 27 seems to
> > paint even faster than that.
>
> Amazingly the attached patch is faster than the mac port on my machine
> (13" retina macbook pro) in the scroll test.
>
> I can’t see that holding for your screen, though.

Here are scroll test results in org.el:

28 with patch - 35s
27 - 4s
26 macport - 10.2s

Question--how are you compiling locally? Maybe there are optimization
flags that you're using that I'm not that's throwing off my
comparison.

I do this:

export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"
export LDFLAGS="-g
-L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.13.sdk/usr/lib
-lxml2 -lz -lpthread -licucore"
export CFLAGS="-g -O0
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2
-I/usr/local/opt/imagemagick@6/include"
export CXXFLAGS="-g -O0"
./autogen.sh
./configure --enable-locallisppath=/usr/local/share/emacs/site-lisp \
            --infodir=$EMACS_DIR/share/info/emacs \
            --prefix=$EMACS_DIR \
            --without-makeinfo
make -j8

> So turns out you need to do some fancy‐pants manoeuvres to scale
> CGLayers correctly. They also appear to draw faster when correctly
> scaled, presumably because it’s not having to scale everything while
> drawing to the screen.

Nice.

> I know exactly what’s causing the glitching, but I’ll come back to
> this tomorrow.

Looking forward to hearing more.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

On Mon, 3 Feb 2020, 00:15 Aaron Jensen, <aaronjensen@gmail.com> wrote:

> export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"
> export LDFLAGS="-g
>
> -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.13.sdk/usr/lib
> -lxml2 -lz -lpthread -licucore"
> export CFLAGS="-g -O0
>
> -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/libxml2
> -I/usr/local/opt/imagemagick@6/include"
> export CXXFLAGS="-g -O0"
> ./autogen.sh
> ./configure --enable-locallisppath=/usr/local/share/emacs/site-lisp \
>             --infodir=$EMACS_DIR/share/info/emacs \
>             --prefix=$EMACS_DIR \
>             --without-makeinfo
> make -j8
>

You appear to be disabling optimisations, I'd try the default -O2.

[-- Attachment #2: Type: text/html, Size: 1420 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Sun, Feb 2, 2020 at 11:39 PM Alan Third <alan@idiocy.org> wrote:
>
> You appear to be disabling optimisations, I'd try the default -O2.

Thanks, that helped a little. 26 seconds now. Still much slower than
macport for some reason.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Mattias Engdegård]

3 feb. 2020 kl. 08.39 skrev Alan Third <alan@idiocy.org>:

> make -j8
> 
> You appear to be disabling optimisations, I'd try the default -O2.

Also make sure all files are rebuilt with -O2, not just those affected by the patch: make clean, just in case.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Mon, Feb 3, 2020 at 8:04 AM Mattias Engdegård <mattiase@acm.org> wrote:
>
> Also make sure all files are rebuilt with -O2, not just those affected by the patch: make clean, just in case.

Thanks, I did do a make clean. Nothing else to do to clean things up, right?

bug#32932: 27.0.50; render bugs on macOS Mojave

[Mattias Engdegård]

3 feb. 2020 kl. 17.05 skrev Aaron Jensen <aaronjensen@gmail.com>:

> Thanks, I did do a make clean. Nothing else to do to clean things up, right?

Don't think so. You could try make bootstrap -- it shouldn't really be necessary but since we're grasping at straws.

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Mon, Feb 03, 2020 at 12:16:25AM -0800, Aaron Jensen wrote:
> On Sun, Feb 2, 2020 at 11:39 PM Alan Third <alan@idiocy.org> wrote:
> >
> > You appear to be disabling optimisations, I'd try the default -O2.
> 
> Thanks, that helped a little. 26 seconds now. Still much slower than
> macport for some reason.

What’s really weird about this is that on my mac the larger the frame
the faster the NS port is in comparison to the mac port.

Perhaps my graphics chipset is just spectacularly bad at whatever the
mac port is doing.

What sort of hardware are you running on? I’ve got a 2015 13" Retina
macbook pro with a max resolution of something like 2550x1600.

Are you testing with -Q?
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Mon, Feb 3, 2020 at 12:44 PM Alan Third <alan@idiocy.org> wrote:
>
> What sort of hardware are you running on? I’ve got a 2015 13" Retina
> macbook pro with a max resolution of something like 2550x1600.

2017 15" MBP, resolution of 2880x1800

> Are you testing with -Q?

Yes, emacs -Q lisp/org/org.el

Also, I'm on Catalina. Not sure if that's a difference too.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sun, Feb 02, 2020 at 04:14:51PM -0800, Aaron Jensen wrote:
> On Sun, Feb 2, 2020 at 2:30 PM Alan Third <alan@idiocy.org> wrote:
> >
> > I know exactly what’s causing the glitching, but I’ll come back to
> > this tomorrow.
> 
> Looking forward to hearing more.

How Cocoa is supposed to work:

When a part of the view must be updated you mark it as dirty. You can
also mark the entire view.

At some point in the NS run loop the graphics context for the window
is set up and drawing is clipped to the areas that were marked as
dirty.

Starting with the first opaque view drawRect is called on each view
that intersects the dirty rectangles. drawRect redraws the contents of
those rectangles.

The dirty rectangles are reset and the process begins again.

The application may not draw to the view outwith drawRect, the only
exception being scrollRect, which appears to require being called
outwith drawRect.

Emacs 27:

Redisplay thinks it’s drawing to the view as it runs, however on NS it
just marks areas as dirty and calling scrollRect.

Once redisplay is completed the run loop starts the process that calls
drawRect.

In the normal case the first opaque view is the NSWindow, which is
blank. It’s just set to the background colour. This immediately clears
anything that was in the dirty rectangles.

Sometimes the NSWindow may be transparent as well in which case the
first opaque view will be the root window. The end result is the same,
the dirty rectangles are now ‘clear’.

EmacsView’s drawRect is called. This calls expose_frame which
draws the contents of the dirty rectangles for real this time.

All is well.

But not always.

Sometimes when expose_frame is called the frame has been marked as
garbaged, so expose_frame refuses to do any drawing. Since the dirty
rectangles have already been cleared by the NSWindow we now have blank
spaces displayed to the user.

Even worse the dirty rectangles are now reset and Emacs has no idea
that those areas are blank so it makes no further attempts to redraw
them.

(IIRC just forcing a display at the end of redisplay, before anything
else has had a chance to garbage the frame, doesn’t work.)

Scrolling is a problem too. scrollRect (which is deprecated and will
be removed) copies the contents of the screen. Sometimes the parts of
the screen it copies contain the cursor. Normally Emacs clears the
cursor before copying parts of the screen, however Cocoa doesn’t let
us draw to the screen outwith drawRect, so we can’t clear the cursor
before calling scrollRect.

The work‐around in use here is to copy the dirty rectangles with the
part of the screen we’re copying. There’s a reasonable chance that we
end up redrawing most of the area that was copied in an attempt to
clear the cursor(s).

Conclusion:

Drawing to a bitmap is just much easier than trying to fix these
issues, although they probably are fixable.

We need a replacement for scrollRect. My hope is that we can save up
the copy commands and replay them within drawRect, that way we can
remove the cursor before copying.

If we make the EmacsView opaque the dirty rectangles aren’t cleared,
however we need to be much more careful about drawing to the whole
view as blank areas aren’t magically cleared for us. And we can never
have a transparent background, which I don’t see as much of a loss,
but some might.

IMO the best solution would be if expose_frame was able to always
redraw the last matrix created by redisplay, however this isn’t
possible, and I’ve never managed to understand enough of redisplay to
know why.

If expose_frame does nothing we could save the dirty rectangles and
re‐mark them sometime after. Probably at the end of the next
redisplay.

I think there were some other problems that I’ve forgotten, but those
were the main issues. I hope this helps explain the issues.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Mon, Feb 03, 2020 at 12:46:59PM -0800, Aaron Jensen wrote:
> On Mon, Feb 3, 2020 at 12:44 PM Alan Third <alan@idiocy.org> wrote:
> >
> > What sort of hardware are you running on? I’ve got a 2015 13" Retina
> > macbook pro with a max resolution of something like 2550x1600.
> 
> 2017 15" MBP, resolution of 2880x1800
> 
> > Are you testing with -Q?
> 
> Yes, emacs -Q lisp/org/org.el
> 
> Also, I'm on Catalina. Not sure if that's a difference too.

Well, I’ve no ideas.

Perhaps this is why people advise not to use CGLayers.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Mon, Feb 3, 2020 at 1:30 PM Alan Third <alan@idiocy.org> wrote:
>
> > Also, I'm on Catalina. Not sure if that's a difference too.
>
> Well, I’ve no ideas.
>
> Perhaps this is why people advise not to use CGLayers.

Thank you for the write up on the current state of the Emacs 27 code.
I'm going to look into it further this weekend hopefully. In the
interim, I wonder if you could send me a Emacs 28 binary compiled on
your machine just to eliminate some difference in compilation as
what's causing the CGLayer slowness for me?

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Thu, Feb 06, 2020 at 10:04:09AM -0800, Aaron Jensen wrote:
> On Mon, Feb 3, 2020 at 1:30 PM Alan Third <alan@idiocy.org> wrote:
> >
> > > Also, I'm on Catalina. Not sure if that's a difference too.
> >
> > Well, I’ve no ideas.
> >
> > Perhaps this is why people advise not to use CGLayers.
> 
> Thank you for the write up on the current state of the Emacs 27 code.
> I'm going to look into it further this weekend hopefully. In the
> interim, I wonder if you could send me a Emacs 28 binary compiled on
> your machine just to eliminate some difference in compilation as
> what's causing the CGLayer slowness for me?

Here’s one, although I don’t know for sure if it’ll work as I’ve not
got a decent way to copy the required dylib files into the .app.

https://drive.google.com/open?id=1wOiEweKZkjiDmV_M3LSjtbFklchSTuzk

If it doesn’t work I’ll try and finish off my script I’ve got half
done that should sort the .dylib files.
-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Fri, Feb 7, 2020 at 12:18 PM Alan Third <alan@idiocy.org> wrote:
>
> Here’s one, although I don’t know for sure if it’ll work as I’ve not
> got a decent way to copy the required dylib files into the .app.

It worked, thank you. It didn't help with the speed, however, and it
had rendering artifacts when run with emacs -Q. As the point moved up,
it left behind part of the rendered cursor on each line (see
attached).

[-- Attachment #2: CleanShot 2020-02-07 at 17.24.26@2x.png --]
[-- Type: image/png, Size: 614427 bytes --]

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Fri, Feb 07, 2020 at 05:26:21PM -0800, Aaron Jensen wrote:
> On Fri, Feb 7, 2020 at 12:18 PM Alan Third <alan@idiocy.org> wrote:
> >
> > Here’s one, although I don’t know for sure if it’ll work as I’ve not
> > got a decent way to copy the required dylib files into the .app.
> 
> It worked, thank you. It didn't help with the speed, however, and it
> had rendering artifacts when run with emacs -Q. As the point moved up,
> it left behind part of the rendered cursor on each line (see
> attached).

Well, I am NOT seeing that here... Anyway, I think we’ve ruled out
some build issue.


-- 
Alan Third

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Sat, Feb 8, 2020 at 6:13 AM Alan Third <alan@idiocy.org> wrote:
>
> Well, I am NOT seeing that here...

Weird.

> Anyway, I think we’ve ruled out some build issue.

Yeah, unfortunately. Are you on Catalina? I can try the build on my
work machine as well. It's a 2019 MBP 16", so pretty close to my 2017
at home, but different. A hardware issue seems unlikely...

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Sat, Feb 08, 2020 at 08:45:25AM -0800, Aaron Jensen wrote:
> 
> Yeah, unfortunately. Are you on Catalina? I can try the build on my
> work machine as well. It's a 2019 MBP 16", so pretty close to my 2017
> at home, but different. A hardware issue seems unlikely...

No, I’m still on Mojave.

Anyway, one last thing to try. I was reading up on how MacVim handled
this same issue, and while their drawing techniques are quite
different, they did find performance problems with CGLayers so
switched to using CGImages. I’ve given that a go and I don’t think
this patch is quite as fast here as the CGLayer one, but it may be
faster for you.

-- 
Alan Third

[-- Attachment #2: 0001-Use-CGImage-instead-of-NSBitmapImageRep-bug-32932.patch --]
[-- Type: text/plain, Size: 8628 bytes --]

From 2b514b8dfac196a7e19ccb4718f3b40afd09d8e0 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sat, 1 Feb 2020 21:17:29 +0000
Subject: [PATCH] Use CGImage instead of NSBitmapImageRep (bug#32932)

---
 src/nsterm.h |   4 +-
 src/nsterm.m | 115 +++++++++++++++++++++++++++++----------------------
 2 files changed, 68 insertions(+), 51 deletions(-)

diff --git a/src/nsterm.h b/src/nsterm.h
index 980ca534cf..7c6197f128 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -418,7 +418,7 @@ #define NSTRACE_UNSILENCE()
    NSWindow *nonfs_window;
    BOOL fs_is_native;
 #ifdef NS_IMPL_COCOA
-   NSBitmapImageRep *drawingBuffer;
+   CGContextRef drawingBuffer;
 #endif
 @public
    struct frame *emacsframe;
@@ -464,7 +464,7 @@ #define NSTRACE_UNSILENCE()
 - (void)focusOnDrawingBuffer;
 #endif
 - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect;
-- (void)createDrawingBufferWithRect:(NSRect)rect;
+- (void)createDrawingBuffer;
 
 /* Non-notification versions of NSView methods. Used for direct calls.  */
 - (void)windowWillEnterFullScreen;
diff --git a/src/nsterm.m b/src/nsterm.m
index 9d427b9b38..8761f65da9 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1141,7 +1141,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 
 #ifdef NS_IMPL_COCOA
   [NSGraphicsContext setCurrentContext:nil];
-  [view display];
 #else
   block_input ();
 
@@ -2853,7 +2852,9 @@ so some key presses (TAB) are swallowed by the system.  */
   ns_unfocus (f);
 
   /* as of 2006/11 or so this is now needed */
-  ns_redraw_scroll_bars (f);
+  /* FIXME: I don't see any reason for this and removing it makes no
+     difference here.  Do we need it for GNUstep?  */
+  //ns_redraw_scroll_bars (f);
   unblock_input ();
 }
 
@@ -3169,18 +3170,6 @@ so some key presses (TAB) are swallowed by the system.  */
 
       NSTRACE_RECT ("fromRect", fromRect);
 
-      /* Because we're drawing into an offscreen buffer which isn't
-         flipped, the images come out upside down.  To work around it
-         we need to do some fancy transforms.  */
-      {
-        NSAffineTransform *transform = [NSAffineTransform transform];
-        [transform translateXBy:0 yBy:NSMaxY(imageRect)];
-        [transform scaleXBy:1 yBy:-1];
-        [transform concat];
-
-        imageRect.origin.y = 0;
-      }
-
       [img drawInRect: imageRect
              fromRect: fromRect
             operation: NSCompositingOperationSourceOver
@@ -3938,11 +3927,6 @@ Function modeled after x_draw_glyph_string_box ().
 
       NSAffineTransform *doTransform = [NSAffineTransform transform];
 
-      /* We have to flip the image around the X axis as the offscreen
-         bitmap we're drawing to is flipped.  */
-      [doTransform scaleXBy:1 yBy:-1];
-      [doTransform translateXBy:0 yBy:-[img size].height];
-
       /* ImageMagick images don't have transforms.  */
       if (img->transform)
         [doTransform appendTransform:img->transform];
@@ -4838,7 +4822,7 @@ in certain situations (rapid incoming events).
   if (NILP (window->vertical_scroll_bar))
     {
       if (width > 0 && height > 0)
-	ns_clear_frame_area (f, left, top, width, height);
+        ns_clear_frame_area (f, left, top, width, height);
 
       bar = [[EmacsScroller alloc] initFrame: r window: win];
       wset_vertical_scroll_bar (window, make_mint_ptr (bar));
@@ -7104,7 +7088,7 @@ - (void) updateFrameSize: (BOOL) delay
          from non-native fullscreen, in other circumstances it appears
          to be a noop.  (bug#28872) */
       wr = NSMakeRect (0, 0, neww, newh);
-      [self createDrawingBufferWithRect:wr];
+      [self createDrawingBuffer];
       [view setFrame: wr];
 
       // To do: consider using [NSNotificationCenter postNotificationName:].
@@ -7444,7 +7428,8 @@ - (instancetype) initFrameFromEmacs: (struct frame *)f
   maximizing_resize = NO;
 #endif
 
-  [self createDrawingBufferWithRect:r];
+  [self setCanDrawConcurrently:YES];
+  [self createDrawingBuffer];
 
   win = [[EmacsWindow alloc]
             initWithContentRect: r
@@ -8229,20 +8214,28 @@ - (instancetype)toggleToolbar: (id)sender
 }
 
 
-- (void)createDrawingBufferWithRect:(NSRect)rect
-  /* Create and store a new NSBitmapImageRep for Emacs to draw
-     into.
+- (void)createDrawingBuffer
+  /* Create and store a new CGLayer for Emacs to draw into.
 
-     Drawing to an offscreen bitmap doesn't work in GNUstep as there's
-     a bug in graphicsContextWithBitmapImageRep
-     (https://savannah.gnu.org/bugs/?38405).  So under GNUstep we
-     retain the old method of drawing direct to the EmacsView.  */
+     We can't do this in GNUstep as there's no CGLayer or equivalent.
+     So under GNUstep we retain the old method of drawing direct to
+     the EmacsView.  */
 {
 #ifdef NS_IMPL_COCOA
+  NSGraphicsContext *screen;
+  CGFloat scale = [[self window] backingScaleFactor];
+  NSRect frame = [self frame];
+
   if (drawingBuffer != nil)
-    [drawingBuffer release];
+    CGContextRelease (drawingBuffer);
+
+  drawingBuffer = CGBitmapContextCreate (nil, NSWidth (frame) * scale,
+                                           NSHeight (frame) * scale,
+                                           8, 0, self.window.colorSpace.CGColorSpace,
+                                         kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Host);
 
-  drawingBuffer = [[self bitmapImageRepForCachingDisplayInRect:rect] retain];
+  CGContextTranslateCTM(drawingBuffer, 0, NSHeight (frame) * scale);
+  CGContextScaleCTM(drawingBuffer, scale, -scale);
 #endif
 }
 
@@ -8250,11 +8243,11 @@ - (void)createDrawingBufferWithRect:(NSRect)rect
 #ifdef NS_IMPL_COCOA
 - (void)focusOnDrawingBuffer
 {
-  /* Creating the graphics context each time is very slow, but it
-     doesn't seem possible to cache and reuse it.  */
-  [NSGraphicsContext
-    setCurrentContext:
-      [NSGraphicsContext graphicsContextWithBitmapImageRep:drawingBuffer]];
+  NSGraphicsContext *buf =
+    [NSGraphicsContext
+        graphicsContextWithCGContext:drawingBuffer flipped:YES];
+
+  [NSGraphicsContext setCurrentContext:buf];
 }
 
 
@@ -8269,7 +8262,7 @@ - (void)windowDidChangeBackingProperties:(NSNotification *)notification
    if (old != new)
      {
        NSRect frame = [self frame];
-       [self createDrawingBufferWithRect:frame];
+       [self createDrawingBuffer];
        ns_clear_frame (emacsframe);
        expose_frame (emacsframe, 0, 0, NSWidth (frame), NSHeight (frame));
      }
@@ -8284,13 +8277,27 @@ - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect
   NSTRACE_RECT ("Destination", dstRect);
 
 #ifdef NS_IMPL_COCOA
-  [drawingBuffer drawInRect:dstRect
-                   fromRect:srcRect
-                  operation:NSCompositingOperationCopy
-                   fraction:1.0
-             respectFlipped:NO
-                      hints:nil];
+  CGImageRef copy;
+  NSAffineTransform *setOrigin = [NSAffineTransform transform];
+  NSRect frame = [self frame];
+  CGFloat xoffset = NSMinX (dstRect) - NSMinX (srcRect);
+  CGFloat yoffset = NSMinY (dstRect) - NSMinY (srcRect);
+
+  [[NSGraphicsContext currentContext] saveGraphicsState];
+
+  NSRectClip (dstRect);
 
+  [setOrigin scaleXBy:1 yBy:-1];
+  [setOrigin translateXBy:xoffset
+                      yBy:-NSHeight (frame) - yoffset];
+  [setOrigin concat];
+
+  copy = CGBitmapContextCreateImage (drawingBuffer);
+  CGContextDrawImage (drawingBuffer, frame, copy);
+
+  CGImageRelease (copy);
+
+  [[NSGraphicsContext currentContext] restoreGraphicsState];
   [self setNeedsDisplayInRect:dstRect];
 #else
   hide_bell();              // Ensure the bell image isn't scrolled.
@@ -8304,6 +8311,20 @@ - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect
 }
 
 
+- (BOOL)wantsUpdateLayer
+{
+    return YES;
+}
+
+
+- (void)updateLayer
+{
+  CGImageRef contentsImage = CGBitmapContextCreateImage(drawingBuffer);
+  self.layer.contents = (id)contentsImage;
+  CGImageRelease(contentsImage);
+}
+
+
 - (void)drawRect: (NSRect)rect
 {
   NSTRACE ("[EmacsView drawRect:" NSTRACE_FMT_RECT "]",
@@ -8313,12 +8334,8 @@ - (void)drawRect: (NSRect)rect
     return;
 
 #ifdef NS_IMPL_COCOA
-  [drawingBuffer drawInRect:rect
-                   fromRect:rect
-                  operation:NSCompositingOperationSourceOver
-                   fraction:1
-             respectFlipped:NO
-                      hints:nil];
+  // CGContextRef ctx = [[NSGraphicsContext currentContext] CGContext];
+  // CGContextDrawLayerInRect (ctx, NSRectToCGRect ([self frame]), drawingBuffer);
 #else
   int x = NSMinX (rect), y = NSMinY (rect);
   int width = NSWidth (rect), height = NSHeight (rect);
-- 
2.24.0

bug#32932: 27.0.50; render bugs on macOS Mojave

[Robert Pluim]

>>>>> On Mon, 10 Feb 2020 07:44:04 +0000, Alan Third <alan@idiocy.org> said:

    Alan> On Sat, Feb 08, 2020 at 08:45:25AM -0800, Aaron Jensen wrote:
    >> 
    >> Yeah, unfortunately. Are you on Catalina? I can try the build on my
    >> work machine as well. It's a 2019 MBP 16", so pretty close to my 2017
    >> at home, but different. A hardware issue seems unlikely...

    Alan> No, I’m still on Mojave.

    Alan> Anyway, one last thing to try. I was reading up on how MacVim handled
    Alan> this same issue, and while their drawing techniques are quite
    Alan> different, they did find performance problems with CGLayers so
    Alan> switched to using CGImages. I’ve given that a go and I don’t think
    Alan> this patch is quite as fast here as the CGLayer one, but it may be
    Alan> faster for you.

Iʼve not measured it, but in interactive use this seems fast enough
for me (as was the previous patch).

Robert

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Sun, Feb 9, 2020 at 11:44 PM Alan Third <alan@idiocy.org> wrote:
>
> Anyway, one last thing to try. I was reading up on how MacVim handled
> this same issue, and while their drawing techniques are quite
> different, they did find performance problems with CGLayers so
> switched to using CGImages. I’ve given that a go and I don’t think
> this patch is quite as fast here as the CGLayer one, but it may be
> faster for you.

9.6s, which is around what 26 macport is, twice as slow as 27, but
about 1/4 the time it took with previous versions of 28. It also
doesn't seem to slow down too much (12.8) when I go full width. It's
still usable, for sure.

No artifacts here as well, so I'd say this is a winner, at least for me.

Thank you for figuring something out.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Mon, Feb 10, 2020 at 7:21 AM Aaron Jensen <aaronjensen@gmail.com> wrote:
>
> On Sun, Feb 9, 2020 at 11:44 PM Alan Third <alan@idiocy.org> wrote:
> >
> > Anyway, one last thing to try. I was reading up on how MacVim handled
> > this same issue, and while their drawing techniques are quite
> > different, they did find performance problems with CGLayers so
> > switched to using CGImages. I’ve given that a go and I don’t think
> > this patch is quite as fast here as the CGLayer one, but it may be
> > faster for you.
>
> 9.6s, which is around what 26 macport is, twice as slow as 27, but
> about 1/4 the time it took with previous versions of 28. It also
> doesn't seem to slow down too much (12.8) when I go full width. It's
> still usable, for sure.

Some more numbers for posterity, using:

(defun scroll-up-benchmark ()
  (interactive)
  (setq frames 0)
  (let ((oldgc gcs-done)
        (oldtime (float-time)))
    (condition-case nil (while t (setq frames (1+ frames)) (scroll-up)
(redisplay))
      (error (message "GCs: %d Elapsed time: %f seconds %d frames %f fps"
                      (- gcs-done oldgc) (- (float-time) oldtime)
frames (/ frames (- (float-time) oldtime)))))))

Emacs 27: 123 FPS (this is faster than my previously reported times
which were only the first run, the 2nd run was 2.16s)
Emacs 28 with CGImage: 28 FPS
Emacs 26 macport: 30 FPS

So, it's still quite a bit slower, but it's usable and it likely won't glitch.

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

On Mon, Feb 10, 2020 at 07:21:30AM -0800, Aaron Jensen wrote:
> On Sun, Feb 9, 2020 at 11:44 PM Alan Third <alan@idiocy.org> wrote:
> >
> > Anyway, one last thing to try. I was reading up on how MacVim handled
> > this same issue, and while their drawing techniques are quite
> > different, they did find performance problems with CGLayers so
> > switched to using CGImages. I’ve given that a go and I don’t think
> > this patch is quite as fast here as the CGLayer one, but it may be
> > faster for you.
> 
> 9.6s, which is around what 26 macport is, twice as slow as 27, but
> about 1/4 the time it took with previous versions of 28. It also
> doesn't seem to slow down too much (12.8) when I go full width. It's
> still usable, for sure.
> 
> No artifacts here as well, so I'd say this is a winner, at least for me.
> 
> Thank you for figuring something out.

I’m happy we’ve got to something usable at last!

New patch attached, it’s basically the same as the last one but
cleaned up and with a proper commit message. It’s not as fast as Emacs
26 and 27, but shouldn’t have any of the visual glitching we’ve seen
in that codebase and is hopefully Fast Enough. I don’t think anyone’s
likely to complain, but I’ll leave it a few days before I push to
master.

Thanks everyone for your help.
-- 
Alan Third

[-- Attachment #2: v3-0001-Use-CGImage-instead-of-NSBitmapImageRep-bug-32932.patch --]
[-- Type: text/plain, Size: 10222 bytes --]

From 97fe485718df20a58a4d48937f78614fc432ced1 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sat, 1 Feb 2020 21:17:29 +0000
Subject: [PATCH v3] Use CGImage instead of NSBitmapImageRep (bug#32932)

* src/nsterm.m (ns_update_end):
(ns_clear_frame): Remove forced draws.
(ns_draw_fringe_bitmap):
(ns_dumpglyphs_image): No longer need to invert images as the context
is already flipped.
([EmacsView updateFrameSize:]):
([EmacsView initFrameFromEmacs:]): Use new function.
([EmacsView createDrawingBuffer]): Replaces createDrawingBufferWithRect:.
([EmacsView focusOnDrawingBuffer]): Set CGImage context.
([EmacsView windowDidChangeBackingProperties:]): Use new function.
([EmacsView copyRect:to:]): Copy using CGImages.
([EmacsView wantsUpdateLayer]):
([EmacsView updateLayer]): New Functions.
([EmacsView drawRect:]): We no longer do anything special here for
Cocoa.
([EmacsView windowDidChangeBackingProperties:]): Fix indentation and
add NSTRACE.
---
 src/nsterm.h |   4 +-
 src/nsterm.m | 152 +++++++++++++++++++++++++++++----------------------
 2 files changed, 90 insertions(+), 66 deletions(-)

diff --git a/src/nsterm.h b/src/nsterm.h
index 980ca534cf..7c6197f128 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -418,7 +418,7 @@ #define NSTRACE_UNSILENCE()
    NSWindow *nonfs_window;
    BOOL fs_is_native;
 #ifdef NS_IMPL_COCOA
-   NSBitmapImageRep *drawingBuffer;
+   CGContextRef drawingBuffer;
 #endif
 @public
    struct frame *emacsframe;
@@ -464,7 +464,7 @@ #define NSTRACE_UNSILENCE()
 - (void)focusOnDrawingBuffer;
 #endif
 - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect;
-- (void)createDrawingBufferWithRect:(NSRect)rect;
+- (void)createDrawingBuffer;
 
 /* Non-notification versions of NSView methods. Used for direct calls.  */
 - (void)windowWillEnterFullScreen;
diff --git a/src/nsterm.m b/src/nsterm.m
index 9d427b9b38..567f3b3794 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1141,7 +1141,6 @@ static NSRect constrain_frame_rect(NSRect frameRect, bool isFullscreen)
 
 #ifdef NS_IMPL_COCOA
   [NSGraphicsContext setCurrentContext:nil];
-  [view display];
 #else
   block_input ();
 
@@ -2853,7 +2852,9 @@ so some key presses (TAB) are swallowed by the system.  */
   ns_unfocus (f);
 
   /* as of 2006/11 or so this is now needed */
-  ns_redraw_scroll_bars (f);
+  /* FIXME: I don't see any reason for this and removing it makes no
+     difference here.  Do we need it for GNUstep?  */
+  //ns_redraw_scroll_bars (f);
   unblock_input ();
 }
 
@@ -3169,18 +3170,6 @@ so some key presses (TAB) are swallowed by the system.  */
 
       NSTRACE_RECT ("fromRect", fromRect);
 
-      /* Because we're drawing into an offscreen buffer which isn't
-         flipped, the images come out upside down.  To work around it
-         we need to do some fancy transforms.  */
-      {
-        NSAffineTransform *transform = [NSAffineTransform transform];
-        [transform translateXBy:0 yBy:NSMaxY(imageRect)];
-        [transform scaleXBy:1 yBy:-1];
-        [transform concat];
-
-        imageRect.origin.y = 0;
-      }
-
       [img drawInRect: imageRect
              fromRect: fromRect
             operation: NSCompositingOperationSourceOver
@@ -3938,11 +3927,6 @@ Function modeled after x_draw_glyph_string_box ().
 
       NSAffineTransform *doTransform = [NSAffineTransform transform];
 
-      /* We have to flip the image around the X axis as the offscreen
-         bitmap we're drawing to is flipped.  */
-      [doTransform scaleXBy:1 yBy:-1];
-      [doTransform translateXBy:0 yBy:-[img size].height];
-
       /* ImageMagick images don't have transforms.  */
       if (img->transform)
         [doTransform appendTransform:img->transform];
@@ -7104,7 +7088,7 @@ - (void) updateFrameSize: (BOOL) delay
          from non-native fullscreen, in other circumstances it appears
          to be a noop.  (bug#28872) */
       wr = NSMakeRect (0, 0, neww, newh);
-      [self createDrawingBufferWithRect:wr];
+      [self createDrawingBuffer];
       [view setFrame: wr];
 
       // To do: consider using [NSNotificationCenter postNotificationName:].
@@ -7444,7 +7428,7 @@ - (instancetype) initFrameFromEmacs: (struct frame *)f
   maximizing_resize = NO;
 #endif
 
-  [self createDrawingBufferWithRect:r];
+  [self createDrawingBuffer];
 
   win = [[EmacsWindow alloc]
             initWithContentRect: r
@@ -8229,52 +8213,65 @@ - (instancetype)toggleToolbar: (id)sender
 }
 
 
-- (void)createDrawingBufferWithRect:(NSRect)rect
-  /* Create and store a new NSBitmapImageRep for Emacs to draw
-     into.
+#ifdef NS_IMPL_COCOA
+- (void)createDrawingBuffer
+  /* Create and store a new CGGraphicsContext for Emacs to draw into.
 
-     Drawing to an offscreen bitmap doesn't work in GNUstep as there's
-     a bug in graphicsContextWithBitmapImageRep
-     (https://savannah.gnu.org/bugs/?38405).  So under GNUstep we
-     retain the old method of drawing direct to the EmacsView.  */
+     We can't do this in GNUstep as there's no equivalent, so under
+     GNUstep we retain the old method of drawing direct to the
+     EmacsView.  */
 {
-#ifdef NS_IMPL_COCOA
+  NSTRACE ("EmacsView createDrawingBuffer]");
+
+  NSGraphicsContext *screen;
+  CGColorSpaceRef colorSpace = [[[self window] colorSpace] CGColorSpace];
+  CGFloat scale = [[self window] backingScaleFactor];
+  NSRect frame = [self frame];
+
   if (drawingBuffer != nil)
-    [drawingBuffer release];
+    CGContextRelease (drawingBuffer);
 
-  drawingBuffer = [[self bitmapImageRepForCachingDisplayInRect:rect] retain];
-#endif
+  drawingBuffer = CGBitmapContextCreate (nil, NSWidth (frame) * scale, NSHeight (frame) * scale,
+                                         8, 0, colorSpace,
+                                         kCGImageAlphaPremultipliedFirst | kCGBitmapByteOrder32Host);
+
+  /* This fixes the scale to match the backing scale factor, and flips the image.  */
+  CGContextTranslateCTM(drawingBuffer, 0, NSHeight (frame) * scale);
+  CGContextScaleCTM(drawingBuffer, scale, -scale);
 }
 
 
-#ifdef NS_IMPL_COCOA
 - (void)focusOnDrawingBuffer
 {
-  /* Creating the graphics context each time is very slow, but it
-     doesn't seem possible to cache and reuse it.  */
-  [NSGraphicsContext
-    setCurrentContext:
-      [NSGraphicsContext graphicsContextWithBitmapImageRep:drawingBuffer]];
+  NSTRACE ("EmacsView focusOnDrawingBuffer]");
+
+  NSGraphicsContext *buf =
+    [NSGraphicsContext
+        graphicsContextWithCGContext:drawingBuffer flipped:YES];
+
+  [NSGraphicsContext setCurrentContext:buf];
 }
 
 
 - (void)windowDidChangeBackingProperties:(NSNotification *)notification
   /* Update the drawing buffer when the backing scale factor changes.  */
 {
-   CGFloat old = [[[notification userInfo]
+  NSTRACE ("EmacsView windowDidChangeBackingProperties:]");
+
+  CGFloat old = [[[notification userInfo]
                     objectForKey:@"NSBackingPropertyOldScaleFactorKey"]
-                   doubleValue];
-   CGFloat new = [[self window] backingScaleFactor];
+                  doubleValue];
+  CGFloat new = [[self window] backingScaleFactor];
 
-   if (old != new)
-     {
-       NSRect frame = [self frame];
-       [self createDrawingBufferWithRect:frame];
-       ns_clear_frame (emacsframe);
-       expose_frame (emacsframe, 0, 0, NSWidth (frame), NSHeight (frame));
-     }
+  if (old != new)
+    {
+      NSRect frame = [self frame];
+      [self createDrawingBuffer];
+      ns_clear_frame (emacsframe);
+      expose_frame (emacsframe, 0, 0, NSWidth (frame), NSHeight (frame));
+    }
 }
-#endif
+#endif /* NS_IMPL_COCOA */
 
 
 - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect
@@ -8284,13 +8281,31 @@ - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect
   NSTRACE_RECT ("Destination", dstRect);
 
 #ifdef NS_IMPL_COCOA
-  [drawingBuffer drawInRect:dstRect
-                   fromRect:srcRect
-                  operation:NSCompositingOperationCopy
-                   fraction:1.0
-             respectFlipped:NO
-                      hints:nil];
+  CGImageRef copy;
+  NSRect frame = [self frame];
+  NSAffineTransform *setOrigin = [NSAffineTransform transform];
+
+  [[NSGraphicsContext currentContext] saveGraphicsState];
+
+  /* Set the clipping before messing with the buffer's
+     orientation.  */
+  NSRectClip (dstRect);
+
+  /* Unflip the buffer as the copied image will be unflipped, and
+     offset the top left so when we draw back into the buffer the
+     correct part of the image is drawn.  */
+  CGContextScaleCTM(drawingBuffer, 1, -1);
+  CGContextTranslateCTM(drawingBuffer, 0, -NSHeight (frame)
+                        - (NSMinY (dstRect) - NSMinY (srcRect)));
+
+  /* Take a copy of the buffer and then draw it back to the buffer,
+     limited by the clipping rectangle.  */
+  copy = CGBitmapContextCreateImage (drawingBuffer);
+  CGContextDrawImage (drawingBuffer, frame, copy);
+
+  CGImageRelease (copy);
 
+  [[NSGraphicsContext currentContext] restoreGraphicsState];
   [self setNeedsDisplayInRect:dstRect];
 #else
   hide_bell();              // Ensure the bell image isn't scrolled.
@@ -8304,6 +8319,24 @@ - (void)copyRect:(NSRect)srcRect to:(NSRect)dstRect
 }
 
 
+#ifdef NS_IMPL_COCOA
+- (BOOL)wantsUpdateLayer
+{
+    return YES;
+}
+
+
+- (void)updateLayer
+{
+  NSTRACE ("EmacsView updateLayer]");
+
+  CGImageRef contentsImage = CGBitmapContextCreateImage(drawingBuffer);
+  self.layer.contents = (id)contentsImage;
+  CGImageRelease(contentsImage);
+}
+#endif
+
+
 - (void)drawRect: (NSRect)rect
 {
   NSTRACE ("[EmacsView drawRect:" NSTRACE_FMT_RECT "]",
@@ -8312,14 +8345,6 @@ - (void)drawRect: (NSRect)rect
   if (!emacsframe || !emacsframe->output_data.ns)
     return;
 
-#ifdef NS_IMPL_COCOA
-  [drawingBuffer drawInRect:rect
-                   fromRect:rect
-                  operation:NSCompositingOperationSourceOver
-                   fraction:1
-             respectFlipped:NO
-                      hints:nil];
-#else
   int x = NSMinX (rect), y = NSMinY (rect);
   int width = NSWidth (rect), height = NSHeight (rect);
 
@@ -8327,7 +8352,6 @@ - (void)drawRect: (NSRect)rect
   block_input ();
   expose_frame (emacsframe, x, y, width, height);
   unblock_input ();
-#endif
 }
 
 
-- 
2.24.0

bug#32932: 27.0.50; render bugs on macOS Mojave

[Aaron Jensen]

On Mon, Feb 10, 2020 at 1:33 PM Alan Third <alan@idiocy.org> wrote:
>
> I’m happy we’ve got to something usable at last!

Definitely, thank you for your diligence.

> New patch attached, it’s basically the same as the last one but
> cleaned up and with a proper commit message. It’s not as fast as Emacs
> 26 and 27, but shouldn’t have any of the visual glitching we’ve seen
> in that codebase and is hopefully Fast Enough. I don’t think anyone’s
> likely to complain, but I’ll leave it a few days before I push to
> master.

Just tested, similar results, so no new concern from me.

Thanks,

Aaron

bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Thu, Feb 13, 2020 at 09:24:49AM -0800, Aaron Jensen wrote:
> On Mon, Feb 10, 2020 at 1:33 PM Alan Third <alan@idiocy.org> wrote:
> >
> > I’m happy we’ve got to something usable at last!
> 
> Definitely, thank you for your diligence.
> 
> > New patch attached, it’s basically the same as the last one but
> > cleaned up and with a proper commit message. It’s not as fast as Emacs
> > 26 and 27, but shouldn’t have any of the visual glitching we’ve seen
> > in that codebase and is hopefully Fast Enough. I don’t think anyone’s
> > likely to complain, but I’ll leave it a few days before I push to
> > master.
> 
> Just tested, similar results, so no new concern from me.

Thanks. Pushed to live.

I believe this bug report is still marked as done so I don’t think I
need to close it.
-- 
Alan Third