GNU bug report logs -
#32932
27.0.50; render bugs on macOS Mojave
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32932 in the body.
You can then email your comments to 32932 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 04 Oct 2018 13:07:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Aaron Jensen <aaronjensen <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 04 Oct 2018 13:07:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 04 Oct 2018 14:08:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, 4 Oct 2018, 14:07 Aaron Jensen, <aaronjensen <at> 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.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 04 Oct 2018 17:30:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> From: Alan Third <athird <at> googlemail.com>
> Date: Thu, 4 Oct 2018 15:07:13 +0100
>
> On Thu, 4 Oct 2018, 14:07 Aaron Jensen, <aaronjensen <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 04 Oct 2018 17:50:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On October 4, 2018 at 7:07:25 AM, Alan Third
(athird <at> googlemail.com(mailto:athird <at> 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
[out.tar.gz (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 04 Oct 2018 18:26:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> googlemail.com(mailto:athird <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 04 Oct 2018 18:46:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 04 Oct 2018 19:44:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 04 Oct 2018 21:53:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> idiocy.org(mailto:alan <at> 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
[0001-Fix-occasional-redraw-error-bug-32932.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 04 Oct 2018 23:04:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 4, 2018 at 2:51:58 PM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 09 Oct 2018 06:37:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On October 4, 2018 at 4:03:14 PM, Aaron Jensen
(aaronjensen <at> gmail.com(mailto:aaronjensen <at> gmail.com)) wrote:
> On October 4, 2018 at 2:51:58 PM, Alan Third (alan <at> idiocy.org(mailto:alan <at> 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
[screencast 2018-10-08 22-15-50.mp4 (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 09 Oct 2018 07:16:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gmail.com> wrote:
> On October 4, 2018 at 4:03:14 PM, Aaron Jensen
> (aaronjensen <at> gmail.com(mailto:aaronjensen <at> gmail.com)) wrote:
>
> > On October 4, 2018 at 2:51:58 PM, Alan Third (alan <at> idiocy.org(mailto:
> alan <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Wed, 10 Oct 2018 18:29:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 11 Oct 2018 03:41:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 10, 2018 at 11:27:54 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 14 Oct 2018 08:21:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 10, 2018 at 8:40:18 PM, Aaron Jensen
(aaronjensen <at> gmail.com(mailto:aaronjensen <at> gmail.com)) wrote:
> On October 10, 2018 at 11:27:54 AM, Alan Third (alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 14 Oct 2018 09:05:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thank you for suggestion. I will try it out as well.
On Sun, Oct 14, 2018 at 11:19 Aaron Jensen <aaronjensen <at> gmail.com> wrote:
> On October 10, 2018 at 8:40:18 PM, Aaron Jensen
> (aaronjensen <at> gmail.com(mailto:aaronjensen <at> gmail.com)) wrote:
>
> > On October 10, 2018 at 11:27:54 AM, Alan Third (alan <at> idiocy.org(mailto:
> alan <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 14 Oct 2018 18:21:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gmail.com(mailto:aaronjensen <at> gmail.com)) wrote:
>
> > On October 10, 2018 at 11:27:54 AM, Alan Third (alan <at> idiocy.org(mailto:alan <at> 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
[0001-Fix-some-NS-drawing-issues-bug-32932.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 14 Oct 2018 20:18:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 14, 2018 at 11:20:17 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 16 Oct 2018 04:54:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 16 Oct 2018 08:40:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> idiocy.org(mailto:alan <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 16 Oct 2018 19:05:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 15, 2018 at 9:53:30 PM, Boris Buliga
(boris <at> d12frosted.io(mailto:boris <at> d12frosted.io)) wrote:
> Will check. Thank you for additional instructions :)
No problem.
> > On October 14, 2018 at 11:20:17 AM, Alan Third
> > (alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 19 Oct 2018 16:28:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 16, 2018 at 12:04:19 PM, Aaron Jensen
(aaronjensen <at> gmail.com(mailto:aaronjensen <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 19 Oct 2018 18:49:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> gmail.com(mailto:aaronjensen <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 19 Oct 2018 19:25:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Fri, Oct 19, 2018 at 11:48 AM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 20 Oct 2018 20:05:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 23 Oct 2018 02:16:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 20, 2018 at 1:04:47 PM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Wed, 24 Oct 2018 10:43:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 29 Oct 2018 02:19:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 24, 2018 at 3:42:47 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 29 Oct 2018 16:10:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> idiocy.org(mailto:alan <at> 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
[0001-Fix-more-drawing-bugs-in-NS-port-bug-32932.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 29 Oct 2018 17:43:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> idiocy.org(mailto:alan <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 30 Oct 2018 05:57:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 29, 2018 at 9:09:48 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 30 Oct 2018 15:36:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gmail.com> wrote:
> On October 29, 2018 at 9:09:48 AM, Alan Third
> (alan <at> idiocy.org(mailto:alan <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Wed, 31 Oct 2018 17:14:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Wed, 31 Oct 2018 22:00:03 GMT)
Full text and
rfc822 format available.
Message #101 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 04:26:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 31, 2018 at 2:59:54 PM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 04:52:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On October 31, 2018 at 10:13:01 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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.
[line.gif (image/gif, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 05:00:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> On October 31, 2018 at 10:13:01 AM, Alan Third (alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 05:12:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 31, 2018 at 9:58:59 PM, Aaron Jensen
(aaronjensen <at> gmail.com(mailto:aaronjensen <at> gmail.com)) wrote:
> > On October 31, 2018 at 10:13:01 AM, Alan Third (alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 06:14:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gmail.com> wrote:
> On October 31, 2018 at 9:58:59 PM, Aaron Jensen
> (aaronjensen <at> gmail.com(mailto:aaronjensen <at> gmail.com)) wrote:
>
> > > On October 31, 2018 at 10:13:01 AM, Alan Third (alan <at> idiocy.org
> (mailto:alan <at> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 06:52:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On October 31, 2018 at 11:13:53 PM, Boris Buliga
(boris <at> d12frosted.io(mailto:boris <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 18:12:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Wed, 31 Oct 2018 23:51:42 -0700
> Cc: Alan Third <alan <at> idiocy.org>, 32932 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 19:53:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 1, 2018 at 11:12:14 AM, Eli Zaretskii
(eliz <at> gnu.org(mailto:eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 20:14:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Thu, 1 Nov 2018 12:52:43 -0700
> Cc: 32932 <at> debbugs.gnu.org, boris <at> d12frosted.io, alan <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 20:30:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 1, 2018 at 1:13:05 PM, Eli Zaretskii
(eliz <at> gnu.org(mailto:eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 01 Nov 2018 22:56:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Thu, Nov 01, 2018 at 08:10:53PM +0200, Eli Zaretskii wrote:
> > From: Aaron Jensen <aaronjensen <at> gmail.com>
> > Date: Wed, 31 Oct 2018 23:51:42 -0700
> > Cc: Alan Third <alan <at> idiocy.org>, 32932 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 09:24:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Thu, 1 Nov 2018 13:29:40 -0700
> Cc: alan <at> idiocy.org, 32932 <at> debbugs.gnu.org, boris <at> d12frosted.io
>
> On November 1, 2018 at 1:13:05 PM, Eli Zaretskii
> (eliz <at> gnu.org(mailto:eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 09:32:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 1 Nov 2018 22:55:19 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: Aaron Jensen <aaronjensen <at> gmail.com>, boris <at> d12frosted.io,
> 32932 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 17:57:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On November 3, 2018 at 2:24:10 AM, Eli Zaretskii (eliz <at> gnu.org(mailto:
eliz <at> 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.
[Message part 2 (text/html, inline)]
[line.gif (image/gif, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 17:58:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 1, 2018 at 3:55:23 PM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 18:19:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sat, 3 Nov 2018 10:56:14 -0700
> Cc: alan <at> idiocy.org, boris <at> d12frosted.io, 32932 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 19:10:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 20:37:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org>
> > Cc: Aaron Jensen <aaronjensen <at> gmail.com>, boris <at> d12frosted.io,
> > 32932 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 20:52:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 21:04:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 3 Nov 2018 20:36:35 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: aaronjensen <at> gmail.com, boris <at> d12frosted.io, 32932 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 03 Nov 2018 23:57:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 3, 2018 at 1:51:24 PM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 04 Nov 2018 13:25:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 04 Nov 2018 13:26:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 04 Nov 2018 17:14:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 4, 2018 at 5:24:58 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 04 Nov 2018 18:29:01 GMT)
Full text and
rfc822 format available.
Message #176 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sun, 4 Nov 2018 09:12:55 -0800
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 32932 <at> debbugs.gnu.org, boris <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 04 Nov 2018 20:12:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 05 Nov 2018 16:12:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 4, 2018 at 12:11:52 PM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 05 Nov 2018 16:21:02 GMT)
Full text and
rfc822 format available.
Message #185 received at 32932 <at> debbugs.gnu.org (full text, mbox):
Answering below in case itâs still helpful.
On November 3, 2018 at 11:19:28 AM, Eli Zaretskii
(eliz <at> gnu.org(mailto:eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 05 Nov 2018 18:56:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 06 Nov 2018 04:05:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 5, 2018 at 10:55:20 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 06 Nov 2018 14:59:01 GMT)
Full text and
rfc822 format available.
Message #194 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 5, 2018 at 8:04:35 PM, Aaron Jensen
(aaronjensen <at> gmail.com(mailto:aaronjensen <at> gmail.com)) wrote:
> On November 5, 2018 at 10:55:20 AM, Alan Third (alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 08 Nov 2018 15:22:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 08 Nov 2018 15:37:01 GMT)
Full text and
rfc822 format available.
Message #200 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 8 Nov 2018 15:21:17 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 32932 <at> debbugs.gnu.org,
> boris <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 08 Nov 2018 16:18:01 GMT)
Full text and
rfc822 format available.
Message #203 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 32932 <at> debbugs.gnu.org,
> > boris <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 08 Nov 2018 16:29:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 8, 2018 at 8:17:21 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 08 Nov 2018 16:53:02 GMT)
Full text and
rfc822 format available.
Message #209 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 8 Nov 2018 16:17:15 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: aaronjensen <at> gmail.com, 32932 <at> debbugs.gnu.org, boris <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 08 Nov 2018 23:22:02 GMT)
Full text and
rfc822 format available.
Message #212 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> idiocy.org(mailto:alan <at> 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
[0001-Further-changes-to-NS-drawing-bug-32932.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 08 Nov 2018 23:24:01 GMT)
Full text and
rfc822 format available.
Message #215 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org>
> > Cc: aaronjensen <at> gmail.com, 32932 <at> debbugs.gnu.org, boris <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 09 Nov 2018 01:03:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 8, 2018 at 3:21:19 PM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 09 Nov 2018 08:03:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 8 Nov 2018 23:21:13 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 32932 <at> debbugs.gnu.org,
> boris <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 09 Nov 2018 09:10:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 32932 <at> debbugs.gnu.org (full text, mbox):
* 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 09 Nov 2018 13:46:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 9, 2018 at 1:09:00 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 09 Nov 2018 14:16:01 GMT)
Full text and
rfc822 format available.
Message #230 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 9, 2018 at 5:45:34 AM, Aaron Jensen
(aaronjensen <at> gmail.com(mailto:aaronjensen <at> gmail.com)) wrote:
> On November 9, 2018 at 1:09:00 AM, Alan Third (alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 13 Nov 2018 22:14:01 GMT)
Full text and
rfc822 format available.
Message #233 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[draw-to-buffer.mbox (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Wed, 14 Nov 2018 17:09:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 13, 2018 at 2:13:41 PM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Wed, 14 Nov 2018 18:20:02 GMT)
Full text and
rfc822 format available.
Message #239 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gmail.com wrote:
> On November 13, 2018 at 2:13:41 PM, Alan Third
> (alan <at> idiocy.org(mailto:alan <at> 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
>
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 16 Nov 2018 01:21:01 GMT)
Full text and
rfc822 format available.
Message #242 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 14, 2018 at 10:19:39 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 19 Nov 2018 22:36:01 GMT)
Full text and
rfc822 format available.
Message #245 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 20 Nov 2018 02:31:01 GMT)
Full text and
rfc822 format available.
Message #248 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 19, 2018 at 2:35:51 PM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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 <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 23 Nov 2018 18:19:01 GMT)
Full text and
rfc822 format available.
Message #251 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> idiocy.org(mailto:alan <at> 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
[v3-0001-Fix-more-drawing-bugs-in-NS-port-bug-32932.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 26 Nov 2018 16:21:02 GMT)
Full text and
rfc822 format available.
Message #254 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On November 23, 2018 at 10:17:58 AM, Alan Third
(alan <at> idiocy.org(mailto:alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 27 Nov 2018 01:43:02 GMT)
Full text and
rfc822 format available.
Message #257 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Merged 32932 33891.
Request was from
Alan Third <alan <at> idiocy.org>
to
control <at> debbugs.gnu.org.
(Fri, 28 Dec 2018 21:29:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 25 Jan 2019 14:03:02 GMT)
Full text and
rfc822 format available.
Message #262 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Mon, Nov 26, 2018 at 8:20 AM Aaron Jensen <aaronjensen <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 25 Jan 2019 22:02:02 GMT)
Full text and
rfc822 format available.
Message #265 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Forcibly Merged 32932 33891 36302.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Mon, 23 Sep 2019 23:20:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 11 Nov 2019 18:17:02 GMT)
Full text and
rfc822 format available.
Message #270 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 12 Nov 2019 13:29:02 GMT)
Full text and
rfc822 format available.
Message #273 received at 32932 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 11 Nov 2019 18:16:22 +0000, Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 12 Nov 2019 14:39:02 GMT)
Full text and
rfc822 format available.
Message #276 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 12 Nov 2019, 13:28 Robert Pluim, <rpluim <at> gmail.com> wrote:
> >>>>> On Mon, 11 Nov 2019 18:16:22 +0000, Alan Third <alan <at> 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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 25 Jan 2020 12:45:02 GMT)
Full text and
rfc822 format available.
Message #285 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Tue, Nov 12, 2019 at 02:38:04PM +0000, Alan Third wrote:
> On Tue, 12 Nov 2019, 13:28 Robert Pluim, <rpluim <at> gmail.com> wrote:
>
> > >>>>> On Mon, 11 Nov 2019 18:16:22 +0000, Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 25 Jan 2020 13:39:02 GMT)
Full text and
rfc822 format available.
Message #288 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 25 Jan 2020 12:44:01 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: 32932 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 27 Jan 2020 11:07:01 GMT)
Full text and
rfc822 format available.
Message #291 received at 32932 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sat, 25 Jan 2020 15:37:41 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> Date: Sat, 25 Jan 2020 12:44:01 +0000
>> From: Alan Third <alan <at> idiocy.org>
>> Cc: 32932 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 27 Jan 2020 20:46:01 GMT)
Full text and
rfc822 format available.
Message #294 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> gnu.org> said:
>
> >> Date: Sat, 25 Jan 2020 12:44:01 +0000
> >> From: Alan Third <alan <at> idiocy.org>
> >> Cc: 32932 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 28 Jan 2020 03:22:01 GMT)
Full text and
rfc822 format available.
Message #297 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 27 Jan 2020 20:45:35 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 32932 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 28 Jan 2020 18:24:01 GMT)
Full text and
rfc822 format available.
Message #300 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> idiocy.org>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 32932 <at> 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
Added tag(s) fixed.
Request was from
Alan Third <alan <at> idiocy.org>
to
control <at> debbugs.gnu.org.
(Tue, 28 Jan 2020 18:24:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 28.1, send any further explanations to
32932 <at> debbugs.gnu.org and Aaron Jensen <aaronjensen <at> gmail.com>
Request was from
Alan Third <alan <at> idiocy.org>
to
control <at> debbugs.gnu.org.
(Tue, 28 Jan 2020 18:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 28 Jan 2020 19:36:01 GMT)
Full text and
rfc822 format available.
Message #307 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 28 Jan 2020 20:08:02 GMT)
Full text and
rfc822 format available.
Message #310 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 28 Jan 2020 20:13:02 GMT)
Full text and
rfc822 format available.
Message #313 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jan 28, 2020 at 12:07 PM Eli Zaretskii <eliz <at> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 28 Jan 2020 20:22:02 GMT)
Full text and
rfc822 format available.
Message #316 received at 32932 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Tue, 28 Jan 2020 12:11:20 -0800
> Cc: 32932 <at> debbugs.gnu.org
>
> On Tue, Jan 28, 2020 at 12:07 PM Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Tue, 28 Jan 2020 20:25:01 GMT)
Full text and
rfc822 format available.
Message #319 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Tue, Jan 28, 2020 at 12:21 PM Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Wed, 29 Jan 2020 10:09:01 GMT)
Full text and
rfc822 format available.
Message #322 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Aaron, just as a test can you try disabling powerline?
On Tue, 28 Jan 2020, 19:53 Aaron Jensen, <aaronjensen <at> 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
>
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Wed, 29 Jan 2020 16:33:02 GMT)
Full text and
rfc822 format available.
Message #325 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jan 29, 2020 at 2:08 AM Alan Third <athird <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Wed, 29 Jan 2020 20:05:01 GMT)
Full text and
rfc822 format available.
Message #328 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 30 Jan 2020 01:42:02 GMT)
Full text and
rfc822 format available.
Message #331 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jan 29, 2020 at 12:04 PM Alan Third <alan <at> 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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 30 Jan 2020 19:13:02 GMT)
Full text and
rfc822 format available.
Message #334 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 30 Jan 2020 20:08:02 GMT)
Full text and
rfc822 format available.
Message #337 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jan 30, 2020 at 11:11 AM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 31 Jan 2020 01:17:02 GMT)
Full text and
rfc822 format available.
Message #340 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 31 Jan 2020 14:58:02 GMT)
Full text and
rfc822 format available.
Message #343 received at 32932 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 30 Jan 2020 12:07:18 -0800, Aaron Jensen <aaronjensen <at> gmail.com> said:
Aaron> On Thu, Jan 30, 2020 at 11:11 AM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 31 Jan 2020 20:24:02 GMT)
Full text and
rfc822 format available.
Message #346 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> gmail.com> said:
>
> Aaron> On Thu, Jan 30, 2020 at 11:11 AM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 31 Jan 2020 20:28:02 GMT)
Full text and
rfc822 format available.
Message #349 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 31, 2020 at 12:23 PM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 31 Jan 2020 21:36:02 GMT)
Full text and
rfc822 format available.
Message #352 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 01 Feb 2020 01:27:01 GMT)
Full text and
rfc822 format available.
Message #355 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 31, 2020 at 12:26 PM Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> On Fri, Jan 31, 2020 at 12:23 PM Alan Third <alan <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 01 Feb 2020 14:23:02 GMT)
Full text and
rfc822 format available.
Message #358 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> gmail.com> wrote:
> >
> > On Fri, Jan 31, 2020 at 12:23 PM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 01 Feb 2020 16:30:02 GMT)
Full text and
rfc822 format available.
Message #361 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Sat, Feb 1, 2020 at 6:22 AM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 01 Feb 2020 21:21:01 GMT)
Full text and
rfc822 format available.
Message #364 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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
[0001-Use-CGLayer-instead-of-NSBitmapImageRep-bug-32932.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 01 Feb 2020 23:07:02 GMT)
Full text and
rfc822 format available.
Message #367 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Sat, Feb 1, 2020 at 1:20 PM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 02 Feb 2020 12:32:01 GMT)
Full text and
rfc822 format available.
Message #370 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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!
[Message part 2 (text/html, inline)]
[Skärmavbild 2020-02-02 kl. 13.25.55.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 02 Feb 2020 13:43:02 GMT)
Full text and
rfc822 format available.
Message #373 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 02 Feb 2020 13:47:01 GMT)
Full text and
rfc822 format available.
Message #376 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 02 Feb 2020 16:51:01 GMT)
Full text and
rfc822 format available.
Message #379 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 2, 2020 at 5:42 AM Alan Third <alan <at> 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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 02 Feb 2020 22:32:02 GMT)
Full text and
rfc822 format available.
Message #382 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> 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
[v2-0001-Use-CGLayer-instead-of-NSBitmapImageRep-bug-32932.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sun, 02 Feb 2020 22:45:02 GMT)
Full text and
rfc822 format available.
Message #385 received at 32932 <at> debbugs.gnu.org (full text, mbox):
2 feb. 2020 kl. 23.30 skrev Alan Third <alan <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 00:16:01 GMT)
Full text and
rfc822 format available.
Message #388 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 2, 2020 at 2:30 PM Alan Third <alan <at> 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 <at> 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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 07:41:02 GMT)
Full text and
rfc822 format available.
Message #391 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 3 Feb 2020, 00:15 Aaron Jensen, <aaronjensen <at> 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 <at> 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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 08:17:01 GMT)
Full text and
rfc822 format available.
Message #394 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 2, 2020 at 11:39 PM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 16:05:01 GMT)
Full text and
rfc822 format available.
Message #397 received at 32932 <at> debbugs.gnu.org (full text, mbox):
3 feb. 2020 kl. 08.39 skrev Alan Third <alan <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 16:06:02 GMT)
Full text and
rfc822 format available.
Message #400 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 3, 2020 at 8:04 AM Mattias Engdegård <mattiase <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 16:10:02 GMT)
Full text and
rfc822 format available.
Message #403 received at 32932 <at> debbugs.gnu.org (full text, mbox):
3 feb. 2020 kl. 17.05 skrev Aaron Jensen <aaronjensen <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 20:45:02 GMT)
Full text and
rfc822 format available.
Message #406 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 20:48:02 GMT)
Full text and
rfc822 format available.
Message #409 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 3, 2020 at 12:44 PM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 21:29:02 GMT)
Full text and
rfc822 format available.
Message #412 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 03 Feb 2020 21:31:01 GMT)
Full text and
rfc822 format available.
Message #415 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 06 Feb 2020 18:05:01 GMT)
Full text and
rfc822 format available.
Message #418 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 3, 2020 at 1:30 PM Alan Third <alan <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Fri, 07 Feb 2020 20:19:01 GMT)
Full text and
rfc822 format available.
Message #421 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 08 Feb 2020 01:27:01 GMT)
Full text and
rfc822 format available.
Message #424 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Feb 7, 2020 at 12:18 PM Alan Third <alan <at> 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).
[CleanShot 2020-02-07 at 17.24.26@2x.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 08 Feb 2020 14:14:01 GMT)
Full text and
rfc822 format available.
Message #427 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Sat, 08 Feb 2020 16:46:02 GMT)
Full text and
rfc822 format available.
Message #430 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Sat, Feb 8, 2020 at 6:13 AM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 10 Feb 2020 07:45:02 GMT)
Full text and
rfc822 format available.
Message #433 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[0001-Use-CGImage-instead-of-NSBitmapImageRep-bug-32932.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 10 Feb 2020 09:00:02 GMT)
Full text and
rfc822 format available.
Message #436 received at 32932 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 10 Feb 2020 07:44:04 +0000, Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 10 Feb 2020 15:22:02 GMT)
Full text and
rfc822 format available.
Message #439 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 9, 2020 at 11:44 PM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 10 Feb 2020 17:15:01 GMT)
Full text and
rfc822 format available.
Message #442 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 10, 2020 at 7:21 AM Aaron Jensen <aaronjensen <at> gmail.com> wrote:
>
> On Sun, Feb 9, 2020 at 11:44 PM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Mon, 10 Feb 2020 21:34:01 GMT)
Full text and
rfc822 format available.
Message #445 received at 32932 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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
[v3-0001-Use-CGImage-instead-of-NSBitmapImageRep-bug-32932.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 13 Feb 2020 17:26:01 GMT)
Full text and
rfc822 format available.
Message #448 received at 32932 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 10, 2020 at 1:33 PM Alan Third <alan <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#32932; Package
emacs.
(Thu, 13 Feb 2020 18:33:01 GMT)
Full text and
rfc822 format available.
Message #451 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 13 Mar 2020 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 93 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.