* Redisplay issue @ 2015-11-27 22:31 Yuan MEI 2015-11-28 8:06 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-11-27 22:31 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 7252 bytes --] Hello, Sometimes when I switch to another virtual desktop then come back to emacs, the entire frame shows only the background color, no letter or only part of the frame is visible. This does not happen all the time though. I just happened to capture a screenshot (attached, I hope the mailing server accepts it.) Thanks, Yuan Here is the info: In GNU Emacs 25.0.50.1 (x86_64-pc-linux-gnu, cairo version 1.14.2) of 2015-11-09 Repository revision: 0f50e5163cf747fcf18124039a82b5156a48316b Windowing system distributor 'The X.Org Foundation', version 11.0.11604000 System Description: NAME=Gentoo Configured using: 'configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib64 --program-suffix=-emacs-25-vcs --infodir=/usr/share/info/emacs-25-vcs --localstatedir=/var --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp --with-gameuser=:gamestat --without-compress-install --with-file-notification=inotify --enable-acl --with-dbus --with-gnutls --with-gpm --with-hesiod --with-kerberos --with-kerberos5 --with-xml2 --without-selinux --without-wide-int --with-zlib --with-sound=alsa --with-x --without-ns --without-gconf --without-gsettings --without-toolkit-scroll-bars --with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-xpm --with-imagemagick --with-xft --with-cairo --without-libotf --without-m17n-flt --with-x-toolkit=no GENTOO_PACKAGE=app-editors/emacs-vcs-25.0.9999-r1 EGIT_BRANCH=master EGIT_VERSION=0f50e5163cf747fcf18124039a82b5156a48316b 'CFLAGS=-O2 -march=native -pipe' CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'' Configured features: XPM JPEG TIFF GIF PNG RSVG CAIRO IMAGEMAGICK SOUND GPM DBUS NOTIFY ACL GNUTLS LIBXML2 FREETYPE XFT ZLIB X11 Important settings: value of $LC_CTYPE: zh_CN.UTF-8 value of $LANG: en_US.iso88591 value of $XMODIFIERS: @im=fcitx locale-coding-system: utf-8-unix Major mode: Text Minor modes in effect: flyspell-mode: t diff-auto-refine-mode: t shell-dirtrack-mode: t display-time-mode: t global-ede-mode: t ede-minor-mode: t global-semantic-mru-bookmark-mode: t global-semanticdb-minor-mode: t global-semantic-idle-completions-mode: t global-semantic-idle-scheduler-mode: t global-semantic-idle-summary-mode: t global-semantic-decoration-mode: t global-semantic-highlight-func-mode: t semantic-mode: t show-paren-mode: t tooltip-mode: t global-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 blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t auto-fill-function: do-auto-fill abbrev-mode: t Recent messages: Wrote /home/ymei/Work/UltrafastImaging/TopmetalElectrodeSim/Makefile Saving file /home/ymei/Work/UltrafastImaging/TopmetalElectrodeSim/Makefile... Wrote /home/ymei/Work/UltrafastImaging/TopmetalElectrodeSim/Makefile Saving file /home/ymei/Work/UltrafastImaging/TopmetalElectrodeSim/Makefile... Wrote /home/ymei/Work/UltrafastImaging/TopmetalElectrodeSim/Makefile next-line: End of buffer scroll-down-command: Beginning of buffer [3 times] previous-line: Beginning of buffer [2 times] next-line: End of buffer [2 times] Making completion list... Quit Load-path shadows: ~/.emacs.d/xref/emacs/xref hides /usr/share/emacs/25.0.50/lisp/progmodes/xref /usr/share/emacs/site-lisp/cjk-latex/thai-word hides /usr/share/emacs/25.0.50/lisp/language/thai-word Features: (shadow sort mail-extr emacsbug message idna dired rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils semantic/analyze/complete semantic/db-typecache semantic/complete eieio-opt semantic/tag-write inversion semantic/bovine/c hideif semantic/bovine/c-by semantic/lex-spp semantic/bovine/gcc semantic/analyze/refs xcscope semantic/tag-file semantic/edit semantic/db-file data-debug cedet-files semantic/bovine/make semantic/decorate/include semantic/db-find semantic/db-ref semantic/dep semantic/analyze semantic/sort semantic/scope semantic/analyze/fcn semantic/bovine/make-by semantic/bovine make-mode vc vc-dispatcher flyspell ispell vc-git diff-mode matlab tempo xrefactory w3m-load slime-banner slime-fancy slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references slime-compiler-notes-tree slime-scratch slime-presentations bridge slime-fuzzy slime-fancy-trace slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc slime-repl elp slime-parse slime gud apropos etags xref project arc-mode archive-mode noutline outline easy-mmode pp hyperspec thingatpt browse-url cl derived ido seq tramp tramp-compat auth-source gnus-util mm-util help-fns mail-prsvr password-cache tramp-loaddefs trampver shell pcomplete format-spec dictionary link connection batch-mode vhdl-mode hippie-exp compile comint ansi-color edmacro kmacro cal-china lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays hol-loaddefs appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs time server cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs ede/speedbar ede/files ede ede/detect ede/base ede/auto ede/source eieio-speedbar speedbar sb-image dframe eieio-custom wid-edit semantic/mru-bookmark ring semantic/db-mode semantic/db eieio-base cl-seq semantic/idle semantic/format ezimage semantic/ctxt semantic/decorate/mode semantic/tag-ls semantic/find semantic/decorate pulse semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw eieio byte-opt bytecomp byte-compile cl-extra help-mode easymenu cconv eieio-core cl-macs gv cl-loaddefs pcase cl-lib mode-local find-func cedet avoid paren advice site-gentoo preview-latex bbdb-autoloads bbdb timezone tex-site auto-loads time-date mule-util china-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core 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 charscript case-table epa-hook jka-cmpr-hook help simple abbrev 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 dbusbind inotify dynamic-setting font-render-setting cairo x multi-tty make-network-process emacs) Memory information: ((conses 16 385636 18540) (symbols 48 40954 0) (miscs 40 425 782) (strings 32 83221 13468) (string-bytes 1 2594038) (vectors 16 37715) (vector-slots 8 881298 6429) (floats 8 1324 371) (intervals 56 6404 0) (buffers 976 24) (heap 1024 37935 2670)) [-- Attachment #2: redisp.png --] [-- Type: image/png, Size: 99606 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-27 22:31 Redisplay issue Yuan MEI @ 2015-11-28 8:06 ` Eli Zaretskii 2015-11-28 8:27 ` Yuan MEI 2015-11-28 21:44 ` joakim 0 siblings, 2 replies; 40+ messages in thread From: Eli Zaretskii @ 2015-11-28 8:06 UTC (permalink / raw) To: Yuan MEI; +Cc: emacs-devel > Date: Fri, 27 Nov 2015 14:31:55 -0800 > From: Yuan MEI <yuan.mei.list@gmail.com> > > Sometimes when I switch to another virtual desktop then come back > to emacs What is a "virtual desktop" in this case? > the entire frame shows only the background color, no letter > or only part of the frame is visible. This does not happen all the > time though. I just happened to capture a screenshot (attached, I > hope the mailing server accepts it.) The screenshot shows a text-mode Emacs frame, AFAICT. Does this happen only with text-mode frames, or do you see that in GUI frames as well? If this happens with text-mode frames only, then that's not an Emacs problem. It's a problem with the terminal emulator (xterm etc.) you are using: it should sense the switch and redraw the display on the low level. When Emacs runs on a TTY, it doesn't listen to any expose or conceal messages sent by the windowing system, so it has no idea that its display was concealed or exposed, and cannot initiate a redisplay in these situations. From the Emacs POV, a TTY frame is the only thing displayed by the console device, and the only way such a frame can be concealed and exposed is by stopping Emacs (with the likes of "C-z") and then resuming it. And these are the only cases a TTY frame will be completely redrawn. GUI frames are different: Emacs gets expose events for them, and should react by redrawing the exposed portion(s) of the frame. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-28 8:06 ` Eli Zaretskii @ 2015-11-28 8:27 ` Yuan MEI 2015-11-28 9:44 ` Eli Zaretskii 2015-11-28 21:44 ` joakim 1 sibling, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-11-28 8:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Sat, Nov 28, 2015 at 12:06 AM, Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Fri, 27 Nov 2015 14:31:55 -0800 >> From: Yuan MEI <yuan.mei.list@gmail.com> >> >> Sometimes when I switch to another virtual desktop then come back >> to emacs > > What is a "virtual desktop" in this case? It is FVWM virtual desktop. I don't know how to put it better. To further narrow down the issue: when the GUI frame is hidden behind another window then exposed, sometimes it exhibits the same symptom. This redisplay issue only happens in a recent version of emacs. I don't recall encountering it for instance half a year ago. > >> the entire frame shows only the background color, no letter >> or only part of the frame is visible. This does not happen all the >> time though. I just happened to capture a screenshot (attached, I >> hope the mailing server accepts it.) > > The screenshot shows a text-mode Emacs frame, AFAICT. Does this > happen only with text-mode frames, or do you see that in GUI frames as > well? The screenshot is in fact a GUI frame. I just configured it to be minimalistic. A `default' frame started with emacs -Q has the same redisplay problem. Yuan ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-28 8:27 ` Yuan MEI @ 2015-11-28 9:44 ` Eli Zaretskii 2015-11-28 20:19 ` Yuan MEI 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-11-28 9:44 UTC (permalink / raw) To: Yuan MEI; +Cc: emacs-devel > Date: Sat, 28 Nov 2015 00:27:13 -0800 > From: Yuan MEI <yuan.mei.list@gmail.com> > Cc: emacs-devel <emacs-devel@gnu.org> > > > The screenshot shows a text-mode Emacs frame, AFAICT. Does this > > happen only with text-mode frames, or do you see that in GUI frames as > > well? > > The screenshot is in fact a GUI frame. I just configured it to be > minimalistic. A `default' frame started with emacs -Q has the same > redisplay problem. Then please see if the scenario in which this happens causes the expose events to be delivered to Emacs by X. If they are, the function expose_frame should be called, and it should perform the necessary redisplay. If these events are not reported, Emacs has no way of knowing that its frame(s) need to be redrawn. Thanks. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-28 9:44 ` Eli Zaretskii @ 2015-11-28 20:19 ` Yuan MEI 2015-11-28 20:49 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-11-28 20:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel >> The screenshot is in fact a GUI frame. I just configured it to be >> minimalistic. A `default' frame started with emacs -Q has the same >> redisplay problem. > > Then please see if the scenario in which this happens causes the > expose events to be delivered to Emacs by X. If they are, the > function expose_frame should be called, and it should perform the > necessary redisplay. If these events are not reported, Emacs has no > way of knowing that its frame(s) need to be redrawn. > > Thanks. It seems the expose event is sent to Emacs and Emacs does respond to it. However the response is not redrawing the entire frame but redrawing part of it. And it looks that some parts that should be redrawn is not. Any suggestions? Thanks, Yuan ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-28 20:19 ` Yuan MEI @ 2015-11-28 20:49 ` Eli Zaretskii 2015-11-29 2:54 ` Yuan MEI 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-11-28 20:49 UTC (permalink / raw) To: Yuan MEI; +Cc: emacs-devel > Date: Sat, 28 Nov 2015 12:19:31 -0800 > From: Yuan MEI <yuan.mei.list@gmail.com> > Cc: emacs-devel <emacs-devel@gnu.org> > > > Then please see if the scenario in which this happens causes the > > expose events to be delivered to Emacs by X. If they are, the > > function expose_frame should be called, and it should perform the > > necessary redisplay. If these events are not reported, Emacs has no > > way of knowing that its frame(s) need to be redrawn. > > > > Thanks. > > It seems the expose event is sent to Emacs and Emacs does respond to > it. However the response is not redrawing the entire frame but > redrawing part of it. And it looks that some parts that should be > redrawn is not. Any suggestions? Can you see if the coordinates of the exposed region, as reported to Emacs, correspond to what is in fact exposed? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-28 20:49 ` Eli Zaretskii @ 2015-11-29 2:54 ` Yuan MEI 2015-11-29 15:42 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-11-29 2:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 554 bytes --] > Can you see if the coordinates of the exposed region, as reported to > Emacs, correspond to what is in fact exposed? Finally I captured a state that although an expose event was sent to Emacs (correctly), Emacs did not redraw. In the attached screenshot, the left-side two windows are Emacs and speedbar frames. The top-right terminal shows the output of xev monitoring the events of the main Emacs window. This state was captured while shifting out of the virtual desktop containing Emacs then shifting in. Emacs did a partial redraw only. Yuan [-- Attachment #2: event.png --] [-- Type: image/png, Size: 315405 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-29 2:54 ` Yuan MEI @ 2015-11-29 15:42 ` Eli Zaretskii 2015-11-29 23:35 ` Yuan MEI 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-11-29 15:42 UTC (permalink / raw) To: Yuan MEI; +Cc: emacs-devel > Date: Sat, 28 Nov 2015 18:54:01 -0800 > From: Yuan MEI <yuan.mei.list@gmail.com> > Cc: emacs-devel <emacs-devel@gnu.org> > > > Can you see if the coordinates of the exposed region, as reported to > > Emacs, correspond to what is in fact exposed? > > Finally I captured a state that although an expose event was sent to > Emacs (correctly), Emacs did not redraw. In the attached screenshot, > the left-side two windows are Emacs and speedbar frames. The > top-right terminal shows the output of xev monitoring the events of > the main Emacs window. This state was captured while shifting out of > the virtual desktop containing Emacs then shifting in. Emacs did a > partial redraw only. I don't understand how Emacs could redraw only partially, if it received the correct coordinates of the exposed region. I might be able to understand how nothing could be redrawn, but partially?.. There's something I'm missing here. Can you build your own Emacs? The display engine can produce a trace of what it does, but it isn't compiled by default. If you can build Emacs, then please configure with --enable-checking='yes,glyphs', then type "M-x trace-redisplay RET" inside Emacs, and post here everything it outputs to stderr starting with "expose_frame" when you succeed to reproduce this again. If you cannot build Emacs, then perhaps you could step with a debugger inside expose_frame and its subroutines, and tell what's going one there. Thanks. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-29 15:42 ` Eli Zaretskii @ 2015-11-29 23:35 ` Yuan MEI 2015-11-30 16:16 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-11-29 23:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > I don't understand how Emacs could redraw only partially, if it > received the correct coordinates of the exposed region. I might be > able to understand how nothing could be redrawn, but partially?.. > There's something I'm missing here. > > Can you build your own Emacs? The display engine can produce a trace > of what it does, but it isn't compiled by default. If you can build > Emacs, then please configure with --enable-checking='yes,glyphs', then > type "M-x trace-redisplay RET" inside Emacs, and post here everything > it outputs to stderr starting with "expose_frame" when you succeed to > reproduce this again. > > If you cannot build Emacs, then perhaps you could step with a debugger > inside expose_frame and its subroutines, and tell what's going one > there. This is when redisplay works normally: >>> right after window exposure redisplay_preserve_echo_area (8) redisplay_internal 0 0x299e030 ( SPEEDBAR): same window start 0x299e030 ( SPEEDBAR): 1 0x1383e60 (*GNU Emacs*): same window start 0x1383e60 (*GNU Emacs*): 1 redisplay_preserve_echo_area (9) redisplay_internal 0 expose_frame (0, 0, 170, 1026) expose_window (1, 1, 168, 1024) expose_window (1, 0, 168, 0) expose_window (1, 0, 168, 0) expose_frame (0, 0, 818, 1026) expose_window (1, 17, 816, 992) expose_window (1, 1009, 816, 16) expose_window (1, 16, 816, 0) expose_window (1, 0, 816, 16) >>> some time pause here, although nothing else (mouse is outside of Emacs, no mouse movement or key press) redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_preserve_echo_area (9) redisplay_internal 0 0x299e030 ( SPEEDBAR): same window start 0x299e030 ( SPEEDBAR): 1 0x1383e60 (*GNU Emacs*): same window start 0x1383e60 (*GNU Emacs*): 1 This is when partial redraw happened: redisplay_preserve_echo_area (8) redisplay_internal 0 0x299e030 ( SPEEDBAR): same window start 0x299e030 ( SPEEDBAR): 1 0x1383e60 (*GNU Emacs*): same window start 0x1383e60 (*GNU Emacs*): 1 redisplay_preserve_echo_area (9) redisplay_internal 0 expose_frame (0, 0, 170, 1026) expose_window (1, 1, 168, 1024) expose_window (1, 0, 168, 0) expose_window (1, 0, 168, 0) expose_frame (0, 0, 818, 1026) expose_window (1, 17, 816, 992) expose_window (1, 1009, 816, 16) expose_window (1, 16, 816, 0) expose_window (1, 0, 816, 16) redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_preserve_echo_area (9) redisplay_internal 0 0x299e030 ( SPEEDBAR): same window start 0x299e030 ( SPEEDBAR): 1 0x1383e60 (*GNU Emacs*): same window start 0x1383e60 (*GNU Emacs*): 1 redisplay_preserve_echo_area (8) redisplay_internal 0 0x299e030 ( SPEEDBAR): same window start 0x299e030 ( SPEEDBAR): 1 0x1383e60 (*GNU Emacs*): same window start 0x1383e60 (*GNU Emacs*): 1 redisplay_preserve_echo_area (9) redisplay_internal 0 redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_preserve_echo_area (9) redisplay_internal 0 0x299e030 ( SPEEDBAR): same window start 0x299e030 ( SPEEDBAR): 1 0x1383e60 (*GNU Emacs*): same window start 0x1383e60 (*GNU Emacs*): 1 >>> I switched to another virtual desktop then came back, redraw remained incorrect but the following showed up in the log redisplay_preserve_echo_area (9) redisplay_internal 0 expose_frame (0, 0, 170, 1026) expose_window (1, 1, 168, 1024) expose_window (1, 0, 168, 0) expose_window (1, 0, 168, 0) expose_frame (0, 0, 818, 1026) expose_window (1, 17, 816, 992) expose_window (1, 1009, 816, 16) expose_window (1, 16, 816, 0) expose_window (1, 0, 816, 16) >>> switched out and back again, finding the entire frame showing only the background color, no menu or status bar redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_preserve_echo_area (9) redisplay_internal 0 0x299e030 ( SPEEDBAR): same window start 0x299e030 ( SPEEDBAR): 1 0x1383e60 (*GNU Emacs*): same window start 0x1383e60 (*GNU Emacs*): 1 expose_frame (0, 0, 170, 1026) expose_window (1, 1, 168, 1024) expose_window (1, 0, 168, 0) expose_window (1, 0, 168, 0) expose_frame (0, 0, 818, 1026) expose_window (1, 17, 816, 992) expose_window (1, 1009, 816, 16) expose_window (1, 16, 816, 0) expose_window (1, 0, 816, 16) >>> a few seconds of time pause, then a few glyphs showed up in the status bar redisplay_preserve_echo_area (8) redisplay_internal 0 0x299e030 ( SPEEDBAR): same window start 0x299e030 ( SPEEDBAR): 1 0x1383e60 (*GNU Emacs*): same window start 0x1383e60 (*GNU Emacs*): 1 redisplay_preserve_echo_area (9) redisplay_internal 0 Any ideas? Thanks, Yuan ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-29 23:35 ` Yuan MEI @ 2015-11-30 16:16 ` Eli Zaretskii 2015-12-01 4:51 ` Yuan MEI 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-11-30 16:16 UTC (permalink / raw) To: Yuan MEI; +Cc: emacs-devel > Date: Sun, 29 Nov 2015 15:35:04 -0800 > From: Yuan MEI <yuan.mei.list@gmail.com> > Cc: emacs-devel <emacs-devel@gnu.org> > > This is when redisplay works normally: > > >>> right after window exposure > > redisplay_preserve_echo_area (8) > redisplay_internal 0 > 0x299e030 ( SPEEDBAR): same window start > 0x299e030 ( SPEEDBAR): 1 > 0x1383e60 (*GNU Emacs*): same window start > 0x1383e60 (*GNU Emacs*): 1 > redisplay_preserve_echo_area (9) > redisplay_internal 0 > expose_frame (0, 0, 170, 1026) > expose_window (1, 1, 168, 1024) > expose_window (1, 0, 168, 0) > expose_window (1, 0, 168, 0) > expose_frame (0, 0, 818, 1026) > expose_window (1, 17, 816, 992) > expose_window (1, 1009, 816, 16) > expose_window (1, 16, 816, 0) > expose_window (1, 0, 816, 16) > > >>> some time pause here, although nothing else (mouse is outside of Emacs, no mouse movement or key press) > > redisplay_preserve_echo_area (8) > redisplay_internal 0 > redisplay_preserve_echo_area (9) > redisplay_internal 0 > 0x299e030 ( SPEEDBAR): same window start > 0x299e030 ( SPEEDBAR): 1 > 0x1383e60 (*GNU Emacs*): same window start > 0x1383e60 (*GNU Emacs*): 1 > > This is when partial redraw happened: > > redisplay_preserve_echo_area (8) > redisplay_internal 0 > 0x299e030 ( SPEEDBAR): same window start > 0x299e030 ( SPEEDBAR): 1 > 0x1383e60 (*GNU Emacs*): same window start > 0x1383e60 (*GNU Emacs*): 1 > redisplay_preserve_echo_area (9) > redisplay_internal 0 > expose_frame (0, 0, 170, 1026) > expose_window (1, 1, 168, 1024) > expose_window (1, 0, 168, 0) > expose_window (1, 0, 168, 0) > expose_frame (0, 0, 818, 1026) > expose_window (1, 17, 816, 992) > expose_window (1, 1009, 816, 16) > expose_window (1, 16, 816, 0) > expose_window (1, 0, 816, 16) > redisplay_preserve_echo_area (8) > redisplay_internal 0 > redisplay_preserve_echo_area (9) > redisplay_internal 0 > 0x299e030 ( SPEEDBAR): same window start > 0x299e030 ( SPEEDBAR): 1 > 0x1383e60 (*GNU Emacs*): same window start > 0x1383e60 (*GNU Emacs*): 1 > redisplay_preserve_echo_area (8) > redisplay_internal 0 > 0x299e030 ( SPEEDBAR): same window start > 0x299e030 ( SPEEDBAR): 1 > 0x1383e60 (*GNU Emacs*): same window start > 0x1383e60 (*GNU Emacs*): 1 > redisplay_preserve_echo_area (9) > redisplay_internal 0 > redisplay_preserve_echo_area (8) > redisplay_internal 0 > redisplay_preserve_echo_area (9) > redisplay_internal 0 > 0x299e030 ( SPEEDBAR): same window start > 0x299e030 ( SPEEDBAR): 1 > 0x1383e60 (*GNU Emacs*): same window start > 0x1383e60 (*GNU Emacs*): 1 > > >>> I switched to another virtual desktop then came back, redraw remained incorrect but the following showed up in the log > > redisplay_preserve_echo_area (9) > redisplay_internal 0 > expose_frame (0, 0, 170, 1026) > expose_window (1, 1, 168, 1024) > expose_window (1, 0, 168, 0) > expose_window (1, 0, 168, 0) > expose_frame (0, 0, 818, 1026) > expose_window (1, 17, 816, 992) > expose_window (1, 1009, 816, 16) > expose_window (1, 16, 816, 0) > expose_window (1, 0, 816, 16) > > >>> switched out and back again, finding the entire frame showing only the background color, no menu or status bar > > redisplay_preserve_echo_area (8) > redisplay_internal 0 > redisplay_preserve_echo_area (9) > redisplay_internal 0 > 0x299e030 ( SPEEDBAR): same window start > 0x299e030 ( SPEEDBAR): 1 > 0x1383e60 (*GNU Emacs*): same window start > 0x1383e60 (*GNU Emacs*): 1 > expose_frame (0, 0, 170, 1026) > expose_window (1, 1, 168, 1024) > expose_window (1, 0, 168, 0) > expose_window (1, 0, 168, 0) > expose_frame (0, 0, 818, 1026) > expose_window (1, 17, 816, 992) > expose_window (1, 1009, 816, 16) > expose_window (1, 16, 816, 0) > expose_window (1, 0, 816, 16) > > >>> a few seconds of time pause, then a few glyphs showed up in the status bar > > redisplay_preserve_echo_area (8) > redisplay_internal 0 > 0x299e030 ( SPEEDBAR): same window start > 0x299e030 ( SPEEDBAR): 1 > 0x1383e60 (*GNU Emacs*): same window start > 0x1383e60 (*GNU Emacs*): 1 > redisplay_preserve_echo_area (9) > redisplay_internal 0 > > Any ideas? The "good" and the "bad" traces are completely identical! Can you add 2 more traces as in the diffs below, recompile, and repeat the experiment? I'd like to be sure that the traces are identical down to the screen line level. Thanks. diff --git a/src/xdisp.c b/src/xdisp.c index 50c5518..1e52d31 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -30580,6 +30580,9 @@ expose_window (struct window *w, XRectangle *fr) } row->clip = fr; + + TRACE ((stderr, "expose_line %d: (%d, %d, %d, %d)\n", + row->y, r.x, r.y, r.width, r.height)); if (expose_line (w, row, &r)) mouse_face_overwritten_p = true; row->clip = NULL; @@ -30607,6 +30610,9 @@ expose_window (struct window *w, XRectangle *fr) row->enabled_p) && row->y < r_bottom) { + + TRACE ((stderr, "expose_line %d: (%d, %d, %d, %d)\n", + row->y, r.x, r.y, r.width, r.height)); if (expose_line (w, row, &r)) mouse_face_overwritten_p = true; } ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-30 16:16 ` Eli Zaretskii @ 2015-12-01 4:51 ` Yuan MEI 2015-12-01 16:01 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-12-01 4:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > The "good" and the "bad" traces are completely identical! > > Can you add 2 more traces as in the diffs below, recompile, and repeat > the experiment? I'd like to be sure that the traces are identical > down to the screen line level. Bad exposure: redisplay_preserve_echo_area (8) redisplay_internal 0 redisplay_preserve_echo_area (9) redisplay_internal 0 0x2d408d0 ( SPEEDBAR): same window start 0x2d408d0 ( SPEEDBAR): 1 0x13cbc30 (HELLO): same window start 0x13cbc30 (HELLO): 1 expose_frame (0, 0, 170, 1026) expose_window (1, 1, 168, 1024) expose_line 0: (0, 0, 168, 1024) expose_line 16: (0, 0, 168, 1024) expose_line 32: (0, 0, 168, 1024) expose_line 48: (0, 0, 168, 1024) expose_line 64: (0, 0, 168, 1024) expose_line 80: (0, 0, 168, 1024) expose_line 96: (0, 0, 168, 1024) expose_line 112: (0, 0, 168, 1024) expose_line 128: (0, 0, 168, 1024) expose_line 144: (0, 0, 168, 1024) expose_line 160: (0, 0, 168, 1024) expose_line 176: (0, 0, 168, 1024) expose_line 192: (0, 0, 168, 1024) expose_line 208: (0, 0, 168, 1024) expose_line 224: (0, 0, 168, 1024) expose_line 240: (0, 0, 168, 1024) expose_line 256: (0, 0, 168, 1024) expose_line 272: (0, 0, 168, 1024) expose_line 288: (0, 0, 168, 1024) expose_line 304: (0, 0, 168, 1024) expose_line 320: (0, 0, 168, 1024) expose_line 336: (0, 0, 168, 1024) expose_line 352: (0, 0, 168, 1024) expose_line 368: (0, 0, 168, 1024) expose_line 384: (0, 0, 168, 1024) expose_line 400: (0, 0, 168, 1024) expose_line 416: (0, 0, 168, 1024) expose_line 432: (0, 0, 168, 1024) expose_line 448: (0, 0, 168, 1024) expose_line 464: (0, 0, 168, 1024) expose_line 480: (0, 0, 168, 1024) expose_line 496: (0, 0, 168, 1024) expose_line 512: (0, 0, 168, 1024) expose_line 528: (0, 0, 168, 1024) expose_line 544: (0, 0, 168, 1024) expose_line 560: (0, 0, 168, 1024) expose_line 576: (0, 0, 168, 1024) expose_line 592: (0, 0, 168, 1024) expose_line 608: (0, 0, 168, 1024) expose_line 624: (0, 0, 168, 1024) expose_line 640: (0, 0, 168, 1024) expose_line 656: (0, 0, 168, 1024) expose_line 672: (0, 0, 168, 1024) expose_line 688: (0, 0, 168, 1024) expose_line 704: (0, 0, 168, 1024) expose_line 720: (0, 0, 168, 1024) expose_line 736: (0, 0, 168, 1024) expose_line 752: (0, 0, 168, 1024) expose_line 768: (0, 0, 168, 1024) expose_line 784: (0, 0, 168, 1024) expose_line 800: (0, 0, 168, 1024) expose_line 816: (0, 0, 168, 1024) expose_line 832: (0, 0, 168, 1024) expose_line 848: (0, 0, 168, 1024) expose_line 864: (0, 0, 168, 1024) expose_line 880: (0, 0, 168, 1024) expose_line 896: (0, 0, 168, 1024) expose_line 912: (0, 0, 168, 1024) expose_line 928: (0, 0, 168, 1024) expose_line 944: (0, 0, 168, 1024) expose_line 960: (0, 0, 168, 1024) expose_line 976: (0, 0, 168, 1024) expose_line 992: (0, 0, 168, 1024) expose_line 1008: (0, 0, 168, 1024) expose_window (1, 0, 168, 0) expose_window (1, 0, 168, 0) expose_frame (0, 0, 818, 1026) expose_window (1, 17, 816, 992) expose_line 0: (0, 0, 816, 992) expose_line 16: (0, 0, 816, 992) expose_line 32: (0, 0, 816, 992) expose_line 48: (0, 0, 816, 992) expose_line 64: (0, 0, 816, 992) expose_line 80: (0, 0, 816, 992) expose_line 101: (0, 0, 816, 992) expose_line 123: (0, 0, 816, 992) expose_line 139: (0, 0, 816, 992) expose_line 158: (0, 0, 816, 992) expose_line 177: (0, 0, 816, 992) expose_line 196: (0, 0, 816, 992) expose_line 222: (0, 0, 816, 992) expose_line 243: (0, 0, 816, 992) expose_line 265: (0, 0, 816, 992) expose_line 286: (0, 0, 816, 992) expose_line 307: (0, 0, 816, 992) expose_line 323: (0, 0, 816, 992) expose_line 339: (0, 0, 816, 992) expose_line 355: (0, 0, 816, 992) expose_line 371: (0, 0, 816, 992) expose_line 390: (0, 0, 816, 992) expose_line 409: (0, 0, 816, 992) expose_line 430: (0, 0, 816, 992) expose_line 447: (0, 0, 816, 992) expose_line 463: (0, 0, 816, 992) expose_line 484: (0, 0, 816, 992) expose_line 505: (0, 0, 816, 992) expose_line 521: (0, 0, 816, 992) expose_line 537: (0, 0, 816, 992) expose_line 559: (0, 0, 816, 992) expose_line 580: (0, 0, 816, 992) expose_line 601: (0, 0, 816, 992) expose_line 622: (0, 0, 816, 992) expose_line 643: (0, 0, 816, 992) expose_line 664: (0, 0, 816, 992) expose_line 685: (0, 0, 816, 992) expose_line 706: (0, 0, 816, 992) expose_line 728: (0, 0, 816, 992) expose_line 747: (0, 0, 816, 992) expose_line 766: (0, 0, 816, 992) expose_line 787: (0, 0, 816, 992) expose_line 806: (0, 0, 816, 992) expose_line 822: (0, 0, 816, 992) expose_line 838: (0, 0, 816, 992) expose_line 857: (0, 0, 816, 992) expose_line 879: (0, 0, 816, 992) expose_line 898: (0, 0, 816, 992) expose_line 917: (0, 0, 816, 992) expose_line 938: (0, 0, 816, 992) expose_line 959: (0, 0, 816, 992) expose_line 975: (0, 0, 816, 992) expose_line 976: (0, 0, 816, 992) expose_window (1, 1009, 816, 16) expose_line 0: (0, 0, 816, 16) expose_window (1, 16, 816, 0) expose_window (1, 0, 816, 16) expose_line 0: (0, 0, 816, 16) redisplay_preserve_echo_area (8) redisplay_internal 0 0x2d408d0 ( SPEEDBAR): same window start 0x2d408d0 ( SPEEDBAR): 1 0x13cbc30 (HELLO): same window start 0x13cbc30 (HELLO): 1 redisplay_preserve_echo_area (9) redisplay_internal 0 Good exposure: redisplay_preserve_echo_area (8) redisplay_internal 0 0x2d408d0 ( SPEEDBAR): same window start 0x2d408d0 ( SPEEDBAR): 1 0x13cbc30 (HELLO): same window start 0x13cbc30 (HELLO): 1 redisplay_preserve_echo_area (9) redisplay_internal 0 expose_frame (0, 0, 170, 1026) expose_window (1, 1, 168, 1024) expose_line 0: (0, 0, 168, 1024) expose_line 16: (0, 0, 168, 1024) expose_line 32: (0, 0, 168, 1024) expose_line 48: (0, 0, 168, 1024) expose_line 64: (0, 0, 168, 1024) expose_line 80: (0, 0, 168, 1024) expose_line 96: (0, 0, 168, 1024) expose_line 112: (0, 0, 168, 1024) expose_line 128: (0, 0, 168, 1024) expose_line 144: (0, 0, 168, 1024) expose_line 160: (0, 0, 168, 1024) expose_line 176: (0, 0, 168, 1024) expose_line 192: (0, 0, 168, 1024) expose_line 208: (0, 0, 168, 1024) expose_line 224: (0, 0, 168, 1024) expose_line 240: (0, 0, 168, 1024) expose_line 256: (0, 0, 168, 1024) expose_line 272: (0, 0, 168, 1024) expose_line 288: (0, 0, 168, 1024) expose_line 304: (0, 0, 168, 1024) expose_line 320: (0, 0, 168, 1024) expose_line 336: (0, 0, 168, 1024) expose_line 352: (0, 0, 168, 1024) expose_line 368: (0, 0, 168, 1024) expose_line 384: (0, 0, 168, 1024) expose_line 400: (0, 0, 168, 1024) expose_line 416: (0, 0, 168, 1024) expose_line 432: (0, 0, 168, 1024) expose_line 448: (0, 0, 168, 1024) expose_line 464: (0, 0, 168, 1024) expose_line 480: (0, 0, 168, 1024) expose_line 496: (0, 0, 168, 1024) expose_line 512: (0, 0, 168, 1024) expose_line 528: (0, 0, 168, 1024) expose_line 544: (0, 0, 168, 1024) expose_line 560: (0, 0, 168, 1024) expose_line 576: (0, 0, 168, 1024) expose_line 592: (0, 0, 168, 1024) expose_line 608: (0, 0, 168, 1024) expose_line 624: (0, 0, 168, 1024) expose_line 640: (0, 0, 168, 1024) expose_line 656: (0, 0, 168, 1024) expose_line 672: (0, 0, 168, 1024) expose_line 688: (0, 0, 168, 1024) expose_line 704: (0, 0, 168, 1024) expose_line 720: (0, 0, 168, 1024) expose_line 736: (0, 0, 168, 1024) expose_line 752: (0, 0, 168, 1024) expose_line 768: (0, 0, 168, 1024) expose_line 784: (0, 0, 168, 1024) expose_line 800: (0, 0, 168, 1024) expose_line 816: (0, 0, 168, 1024) expose_line 832: (0, 0, 168, 1024) expose_line 848: (0, 0, 168, 1024) expose_line 864: (0, 0, 168, 1024) expose_line 880: (0, 0, 168, 1024) expose_line 896: (0, 0, 168, 1024) expose_line 912: (0, 0, 168, 1024) expose_line 928: (0, 0, 168, 1024) expose_line 944: (0, 0, 168, 1024) expose_line 960: (0, 0, 168, 1024) expose_line 976: (0, 0, 168, 1024) expose_line 992: (0, 0, 168, 1024) expose_line 1008: (0, 0, 168, 1024) expose_window (1, 0, 168, 0) expose_window (1, 0, 168, 0) expose_frame (0, 0, 818, 1026) expose_window (1, 17, 816, 992) expose_line 0: (0, 0, 816, 992) expose_line 16: (0, 0, 816, 992) expose_line 32: (0, 0, 816, 992) expose_line 48: (0, 0, 816, 992) expose_line 64: (0, 0, 816, 992) expose_line 80: (0, 0, 816, 992) expose_line 101: (0, 0, 816, 992) expose_line 123: (0, 0, 816, 992) expose_line 139: (0, 0, 816, 992) expose_line 158: (0, 0, 816, 992) expose_line 177: (0, 0, 816, 992) expose_line 196: (0, 0, 816, 992) expose_line 222: (0, 0, 816, 992) expose_line 243: (0, 0, 816, 992) expose_line 265: (0, 0, 816, 992) expose_line 286: (0, 0, 816, 992) expose_line 307: (0, 0, 816, 992) expose_line 323: (0, 0, 816, 992) expose_line 339: (0, 0, 816, 992) expose_line 355: (0, 0, 816, 992) expose_line 371: (0, 0, 816, 992) expose_line 390: (0, 0, 816, 992) expose_line 409: (0, 0, 816, 992) expose_line 430: (0, 0, 816, 992) expose_line 447: (0, 0, 816, 992) expose_line 463: (0, 0, 816, 992) expose_line 484: (0, 0, 816, 992) expose_line 505: (0, 0, 816, 992) expose_line 521: (0, 0, 816, 992) expose_line 537: (0, 0, 816, 992) expose_line 559: (0, 0, 816, 992) expose_line 580: (0, 0, 816, 992) expose_line 601: (0, 0, 816, 992) expose_line 622: (0, 0, 816, 992) expose_line 643: (0, 0, 816, 992) expose_line 664: (0, 0, 816, 992) expose_line 685: (0, 0, 816, 992) expose_line 706: (0, 0, 816, 992) expose_line 728: (0, 0, 816, 992) expose_line 747: (0, 0, 816, 992) expose_line 766: (0, 0, 816, 992) expose_line 787: (0, 0, 816, 992) expose_line 806: (0, 0, 816, 992) expose_line 822: (0, 0, 816, 992) expose_line 838: (0, 0, 816, 992) expose_line 857: (0, 0, 816, 992) expose_line 879: (0, 0, 816, 992) expose_line 898: (0, 0, 816, 992) expose_line 917: (0, 0, 816, 992) expose_line 938: (0, 0, 816, 992) expose_line 959: (0, 0, 816, 992) expose_line 975: (0, 0, 816, 992) expose_line 976: (0, 0, 816, 992) expose_window (1, 1009, 816, 16) expose_line 0: (0, 0, 816, 16) expose_window (1, 16, 816, 0) expose_window (1, 0, 816, 16) expose_line 0: (0, 0, 816, 16) One more piece of information: once Emacs gets into `bad' mode, switching out of the virtual desktop then coming back in several times won't turn Emacs into `good' mode. The way I used to recover was to switch to another Emacs buffer then switch back. Also, it is interesting to see that a few seconds after seeing a completely blank `bad' Emacs frame, a few lines of glyphs show up. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-01 4:51 ` Yuan MEI @ 2015-12-01 16:01 ` Eli Zaretskii 2015-12-02 4:35 ` Yuan MEI 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-12-01 16:01 UTC (permalink / raw) To: Yuan MEI; +Cc: emacs-devel > Date: Mon, 30 Nov 2015 20:51:15 -0800 > From: Yuan MEI <yuan.mei.list@gmail.com> > Cc: emacs-devel <emacs-devel@gnu.org> > > One more piece of information: once Emacs gets into `bad' mode, > switching out of the virtual desktop then coming back in several times > won't turn Emacs into `good' mode. The way I used to recover was to > switch to another Emacs buffer then switch back. Also, it is > interesting to see that a few seconds after seeing a completely blank > `bad' Emacs frame, a few lines of glyphs show up. Thanks. Once again, the traces of handling the expose event are identical between the "good" and the "bad" cases. I have only one more idea: can you build Emacs without Cairo? Cairo changes the way Emacs draws the screen in significant ways, and that is the only part of this puzzle that we didn't verify yet. The traces indicate that everything up to the point where we invoke the drawing code is identical between the "good" and the "bad" cases, and correctly instructs the display back-end to redraw every screen line in the exposed region(s). ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-01 16:01 ` Eli Zaretskii @ 2015-12-02 4:35 ` Yuan MEI 2015-12-02 13:57 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-12-02 4:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > I have only one more idea: can you build Emacs without Cairo? Cairo > changes the way Emacs draws the screen in significant ways, and that > is the only part of this puzzle that we didn't verify yet. The traces > indicate that everything up to the point where we invoke the drawing > code is identical between the "good" and the "bad" cases, and > correctly instructs the display back-end to redraw every screen line > in the exposed region(s). Very interesting. The partial redraw problem seems to be gone when cairo is disabled. I couldn't reproduce the bad case any more. However I encountered another bug when cairo is disabled: did C-h h to bring up HELLO, and Emacs crashed: lisp.h:1543: Emacs fatal error: assertion failed: 0 <= size Fatal error 6: Aborted lisp.h:1543: Emacs fatal error: assertion failed: 0 <= size Aborted Thanks, Yuan ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-02 4:35 ` Yuan MEI @ 2015-12-02 13:57 ` Eli Zaretskii 2015-12-03 4:55 ` Yuan MEI 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-12-02 13:57 UTC (permalink / raw) To: Yuan MEI; +Cc: emacs-devel > Date: Tue, 1 Dec 2015 20:35:43 -0800 > From: Yuan MEI <yuan.mei.list@gmail.com> > Cc: emacs-devel <emacs-devel@gnu.org> > > > I have only one more idea: can you build Emacs without Cairo? Cairo > > changes the way Emacs draws the screen in significant ways, and that > > is the only part of this puzzle that we didn't verify yet. The traces > > indicate that everything up to the point where we invoke the drawing > > code is identical between the "good" and the "bad" cases, and > > correctly instructs the display back-end to redraw every screen line > > in the exposed region(s). > > Very interesting. The partial redraw problem seems to be gone when > cairo is disabled. I couldn't reproduce the bad case any more. > However I encountered another bug when cairo is disabled: did C-h h to > bring up HELLO, and Emacs crashed: > > lisp.h:1543: Emacs fatal error: assertion failed: 0 <= size > Fatal error 6: Aborted > lisp.h:1543: Emacs fatal error: assertion failed: 0 <= size > Aborted When did you last update from the repository? I believe this bug was solved a week ago, in commit d5fdffecdfad305d9c933ae3cad75a5e4e73878c. If your sources include the changes in that commit, please show a GDB backtrace when Emacs aborts. A stub in the dark: does the change below fix the Cairo build, per chance? diff --git a/src/xdisp.c b/src/xdisp.c index d1a10ca..7221032 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -30268,6 +30268,7 @@ expose_area (struct window *w, struct glyph_row *row, XRectangle *r, struct glyph *last; int first_x, start_x, x; + block_input (); if (area == TEXT_AREA && row->fill_line_p) /* If row extends face to end of line write the whole line. */ draw_glyphs (w, 0, row, area, @@ -30310,6 +30311,7 @@ expose_area (struct window *w, struct glyph_row *row, XRectangle *r, first - row->glyphs[area], last - row->glyphs[area], DRAW_NORMAL_TEXT, 0); } + unblock_input (); } ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-02 13:57 ` Eli Zaretskii @ 2015-12-03 4:55 ` Yuan MEI 2015-12-03 7:47 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-12-03 4:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > When did you last update from the repository? I believe this bug was > solved a week ago, in commit d5fdffecdfad305d9c933ae3cad75a5e4e73878c. OK, this problem is gone. > If your sources include the changes in that commit, please show a GDB > backtrace when Emacs aborts. > > A stub in the dark: does the change below fix the Cairo build, per > chance? > > diff --git a/src/xdisp.c b/src/xdisp.c > index d1a10ca..7221032 100644 > --- a/src/xdisp.c > +++ b/src/xdisp.c > @@ -30268,6 +30268,7 @@ expose_area (struct window *w, struct glyph_row *row, XRectangle *r, > struct glyph *last; > int first_x, start_x, x; > > + block_input (); > if (area == TEXT_AREA && row->fill_line_p) > /* If row extends face to end of line write the whole line. */ > draw_glyphs (w, 0, row, area, > @@ -30310,6 +30311,7 @@ expose_area (struct window *w, struct glyph_row *row, XRectangle *r, > first - row->glyphs[area], last - row->glyphs[area], > DRAW_NORMAL_TEXT, 0); > } > + unblock_input (); > } > Unfortunately this did not solve the problem. And I noticed something: comparing with and without cairo, even though the number of lines of text and other geometric parameters are identical (no .Xdefaults or any changes in .emacs.d/, the window (frame) height for with and without cairo are different. Something about font handling are different? Thanks, Yuan ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-03 4:55 ` Yuan MEI @ 2015-12-03 7:47 ` Eli Zaretskii 2015-12-03 8:09 ` Yuan MEI 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-12-03 7:47 UTC (permalink / raw) To: Yuan MEI; +Cc: emacs-devel > Date: Wed, 2 Dec 2015 20:55:25 -0800 > From: Yuan MEI <yuan.mei.list@gmail.com> > Cc: emacs-devel <emacs-devel@gnu.org> > > > + unblock_input (); > > } > > > > Unfortunately this did not solve the problem. That was the only difference I could spot between 2 different code paths into calling the display back-end drawing routines: one which works (the "normal" redisplay), the other that doesn't (when a frame is exposed). I guess at this point we need a Cairo expert to look into this and find out what prevents the correct redisplay. My gut feeling is that it's some buffering at work, and Emacs simply doesn't tell Cairo to "flush" the buffered drawing commands. But I couldn't find the code which would be responsible for that in the "normal" redisplay case. > And I noticed something: comparing with and without cairo, even though > the number of lines of text and other geometric parameters are > identical (no .Xdefaults or any changes in .emacs.d/, the window > (frame) height for with and without cairo are different. Something > about font handling are different? Everything is different with Cairo, including the fonts: the Cairo build has its own font back-end (see ftcrfont.c). How large is the difference? Do you see changes in frame/window dimensions that correlate to those differences in height? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-03 7:47 ` Eli Zaretskii @ 2015-12-03 8:09 ` Yuan MEI 2015-12-03 10:23 ` Eli Zaretskii 2015-12-03 18:16 ` martin rudalics 0 siblings, 2 replies; 40+ messages in thread From: Yuan MEI @ 2015-12-03 8:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > Everything is different with Cairo, including the fonts: the Cairo > build has its own font back-end (see ftcrfont.c). > > How large is the difference? Do you see changes in frame/window > dimensions that correlate to those differences in height? Emacs.Geometry: 100x59+2+2 Without Cairo: Width: 818 Height: 1022 With Cairo: Width: 818 Height: 962 So for the same screen height, I gain 4 lines of text when using Cairo. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-03 8:09 ` Yuan MEI @ 2015-12-03 10:23 ` Eli Zaretskii 2015-12-03 18:16 ` martin rudalics 1 sibling, 0 replies; 40+ messages in thread From: Eli Zaretskii @ 2015-12-03 10:23 UTC (permalink / raw) To: Yuan MEI; +Cc: emacs-devel > Date: Thu, 3 Dec 2015 00:09:04 -0800 > From: Yuan MEI <yuan.mei.list@gmail.com> > Cc: emacs-devel <emacs-devel@gnu.org> > > Emacs.Geometry: 100x59+2+2 > > Without Cairo: > Width: 818 > Height: 1022 > > With Cairo: > Width: 818 > Height: 962 > > So for the same screen height, I gain 4 lines of text when using Cairo. So what is smaller with Cairo? The letters, the gap between the lines, the frame decorations? Where do those extra 60 pixels come from? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-03 8:09 ` Yuan MEI 2015-12-03 10:23 ` Eli Zaretskii @ 2015-12-03 18:16 ` martin rudalics 2015-12-03 21:23 ` Yuan MEI 1 sibling, 1 reply; 40+ messages in thread From: martin rudalics @ 2015-12-03 18:16 UTC (permalink / raw) To: Yuan MEI, Eli Zaretskii; +Cc: emacs-devel > Emacs.Geometry: 100x59+2+2 > > Without Cairo: > Width: 818 > Height: 1022 > > With Cairo: > Width: 818 > Height: 962 > > So for the same screen height, I gain 4 lines of text when using Cairo. What does ‘frame-geometry’ return for those frames? martin ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-03 18:16 ` martin rudalics @ 2015-12-03 21:23 ` Yuan MEI 2015-12-04 8:08 ` martin rudalics 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-12-03 21:23 UTC (permalink / raw) To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel [-- Attachment #1: Type: text/plain, Size: 952 bytes --] >> Emacs.Geometry: 100x59+2+2 >> >> Without Cairo: >> Width: 818 >> Height: 1022 >> >> With Cairo: >> Width: 818 >> Height: 962 >> >> So for the same screen height, I gain 4 lines of text when using Cairo. > > What does ‘frame-geometry’ return for those frames? Without Cairo: ((outer-position 2 . 2) (outer-size 820 . 1044) (external-border-size 1 . 21) (title-bar-size 0 . -20) (menu-bar-external) (menu-bar-size 818 . 17) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 1)) With Cairo: ((outer-position 2 . 2) (outer-size 820 . 984) (external-border-size 1 . 21) (title-bar-size 0 . -20) (menu-bar-external) (menu-bar-size 818 . 16) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 1)) And I attach two screen shots for with and without cairo. To my eyes it is the gap between lines that is different. Yuan [-- Attachment #2: with_cairo.png --] [-- Type: image/png, Size: 122170 bytes --] [-- Attachment #3: without_cairo.png --] [-- Type: image/png, Size: 148246 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-03 21:23 ` Yuan MEI @ 2015-12-04 8:08 ` martin rudalics 2015-12-04 8:30 ` Yuan MEI 0 siblings, 1 reply; 40+ messages in thread From: martin rudalics @ 2015-12-04 8:08 UTC (permalink / raw) To: Yuan MEI; +Cc: Eli Zaretskii, emacs-devel >> What does ‘frame-geometry’ return for those frames? > > Without Cairo: > > ((outer-position 2 . 2) (outer-size 820 . 1044) (external-border-size > 1 . 21) (title-bar-size 0 . -20) -20 is silly. I'll have to look into this. But it has no impact here. > (menu-bar-external) (menu-bar-size > 818 . 17) (tool-bar-external) (tool-bar-position . top) (tool-bar-size > 0 . 0) (internal-border-width . 1)) > > With Cairo: > ((outer-position 2 . 2) (outer-size 820 . 984) (external-border-size 1 > . 21) (title-bar-size 0 . -20) (menu-bar-external) (menu-bar-size 818 > . 16) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 0 . > 0) (internal-border-width . 1)) > > And I attach two screen shots for with and without cairo. To my eyes > it is the gap between lines that is different. I couldn't tell. The menubars differ by one pixel in height. So maybe this one pixel multiplied by the number of lines of the frame could sum up to 60 pixels. Please report also the values returned by (frame-edges nil 'outer-edges) (frame-edges nil 'native-edges) (frame-edges nil 'inner-edges) and (frame-parameters) for each of these frames. Maybe they allow more insight. Thank you, martin ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 8:08 ` martin rudalics @ 2015-12-04 8:30 ` Yuan MEI 2015-12-04 8:48 ` martin rudalics 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-12-04 8:30 UTC (permalink / raw) To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel > Please report also the values returned by > > (frame-edges nil 'outer-edges) > (frame-edges nil 'native-edges) > (frame-edges nil 'inner-edges) > > and > > (frame-parameters) > > for each of these frames. Maybe they allow more insight. Without cairo: (2 2 822 1046) (3 3 821 1025) (4 21 820 1024) ((parent-id . 6305140) (explicit-name) (display . ":0") (visibility . t) (icon-name) (outer-window-id . "41943058") (window-id . "41943058") (top . 2) (left . 2) (buried-buffer-list) (buffer-list #<buffer *scratch*> #<buffer *Minibuf-1*>) (unsplittable) ...) With cairo: (2 2 822 986) (3 3 821 965) (4 20 820 964) ((parent-id . 6311574) (explicit-name) (display . ":0") (visibility . t) (icon-name) (outer-window-id . "41943057") (window-id . "41943057") (top . 2) (left . 2) (buried-buffer-list) (buffer-list #<buffer *scratch*> #<buffer *Messages*> #<buffer *Minibuf-1*>) (unsplittable) ...) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 8:30 ` Yuan MEI @ 2015-12-04 8:48 ` martin rudalics 2015-12-04 8:54 ` Yuan MEI 2015-12-04 8:56 ` martin rudalics 0 siblings, 2 replies; 40+ messages in thread From: martin rudalics @ 2015-12-04 8:48 UTC (permalink / raw) To: Yuan MEI; +Cc: Eli Zaretskii, emacs-devel > (2 2 822 1046) > (3 3 821 1025) > (4 21 820 1024) > ((parent-id . 6305140) (explicit-name) (display . ":0") (visibility . > t) (icon-name) (outer-window-id . "41943058") (window-id . "41943058") > (top . 2) (left . 2) (buried-buffer-list) (buffer-list #<buffer > *scratch*> #<buffer *Minibuf-1*>) (unsplittable) ...) > > With cairo: > > (2 2 822 986) > (3 3 821 965) > (4 20 820 964) > ((parent-id . 6311574) (explicit-name) (display . ":0") (visibility . > t) (icon-name) (outer-window-id . "41943057") (window-id . "41943057") > (top . 2) (left . 2) (buried-buffer-list) (buffer-list #<buffer > *scratch*> #<buffer *Messages*> #<buffer *Minibuf-1*>) (unsplittable) > ...) Please repeat the ‘frame-parameters’ calls with (setq eval-expression-print-length nil) Thanks, martin ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 8:48 ` martin rudalics @ 2015-12-04 8:54 ` Yuan MEI 2015-12-04 8:56 ` martin rudalics 1 sibling, 0 replies; 40+ messages in thread From: Yuan MEI @ 2015-12-04 8:54 UTC (permalink / raw) To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel > Please repeat the ‘frame-parameters’ calls with > > (setq eval-expression-print-length nil) Without cairo: ((parent-id . 6312400) (explicit-name) (display . ":0") (visibility . t) (icon-name) (outer-window-id . "41943058") (window-id . "41943058") (top . 2) (left . 2) (buried-buffer-list) (buffer-list #<buffer *scratch*> #<buffer *Minibuf-1*>) (unsplittable) (minibuffer . #<window 4 on *Minibuf-0*>) (modeline . t) (width . 100) (name . "*scratch* | ") (environment) (cursor-color . "red") (background-mode . dark) (display-type . color) (window-system . x) (fullscreen) (alpha) (scroll-bar-height . 0) (scroll-bar-width . 0) (cursor-type . box) (auto-lower) (auto-raise) (icon-type . t) (tool-bar-position . top) (wait-for-wm . t) (title) (buffer-predicate) (height . 59) (tool-bar-lines . 0) (menu-bar-lines . 1) (scroll-bar-background) (scroll-bar-foreground) (right-fringe . 8) (left-fringe . 8) (line-spacing) (screen-gamma) (border-color . "black") (mouse-color . "yellow") (background-color . "black") (foreground-color . "white") (horizontal-scroll-bars) (vertical-scroll-bars) (bottom-divider-width . 0) (right-divider-width . 0) (internal-border-width . 1) (border-width . 0) (font-parameter . "fontset-xwin") (font . "-bitstream-Bitstream Vera Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1") (font-backend xft)) With cairo: ((parent-id . 6313545) (explicit-name) (display . ":0") (visibility . t) (icon-name) (outer-window-id . "41943057") (window-id . "41943057") (top . 2) (left . 2) (buried-buffer-list) (buffer-list #<buffer *scratch*> #<buffer *Messages*> #<buffer *Minibuf-1*>) (unsplittable) (minibuffer . #<window 4 on *Minibuf-0*>) (modeline . t) (width . 100) (name . "*scratch* | ") (environment) (cursor-color . "red") (background-mode . dark) (display-type . color) (window-system . x) (fullscreen) (alpha) (scroll-bar-height . 0) (scroll-bar-width . 0) (cursor-type . box) (auto-lower) (auto-raise) (icon-type . t) (tool-bar-position . top) (wait-for-wm . t) (title) (buffer-predicate) (height . 59) (tool-bar-lines . 0) (menu-bar-lines . 1) (scroll-bar-background) (scroll-bar-foreground) (right-fringe . 8) (left-fringe . 8) (line-spacing) (screen-gamma) (border-color . "black") (mouse-color . "yellow") (background-color . "black") (foreground-color . "white") (horizontal-scroll-bars) (vertical-scroll-bars) (bottom-divider-width . 0) (right-divider-width . 0) (internal-border-width . 1) (border-width . 0) (font-parameter . "fontset-xwin") (font . "-bitstream-Bitstream Vera Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1") (font-backend ftcr)) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 8:48 ` martin rudalics 2015-12-04 8:54 ` Yuan MEI @ 2015-12-04 8:56 ` martin rudalics 2015-12-04 9:00 ` Yuan MEI 1 sibling, 1 reply; 40+ messages in thread From: martin rudalics @ 2015-12-04 8:56 UTC (permalink / raw) To: Yuan MEI; +Cc: Eli Zaretskii, emacs-devel > Please repeat the ‘frame-parameters’ calls with > > (setq eval-expression-print-length nil) And also tell us the values of (frame-char-height) for each of the frames. Thanks, martin ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 8:56 ` martin rudalics @ 2015-12-04 9:00 ` Yuan MEI 2015-12-04 9:05 ` martin rudalics 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-12-04 9:00 UTC (permalink / raw) To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel > And also tell us the values of > > (frame-char-height) > > for each of the frames. Without cairo: 17 (#o21, #x11, ?\C-q) With cairo: 16 (#o20, #x10, ?\C-p) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 9:00 ` Yuan MEI @ 2015-12-04 9:05 ` martin rudalics 2015-12-04 9:47 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: martin rudalics @ 2015-12-04 9:05 UTC (permalink / raw) To: Yuan MEI; +Cc: Eli Zaretskii, emacs-devel > Without cairo: > > 17 (#o21, #x11, ?\C-q) > > With cairo: > > 16 (#o20, #x10, ?\C-p) So it's the Cairo font backend. 59 text lines plus one menu bar line give the 60 pixels difference. martin ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 9:05 ` martin rudalics @ 2015-12-04 9:47 ` Eli Zaretskii 2015-12-04 10:21 ` martin rudalics 2015-12-05 0:25 ` YAMAMOTO Mitsuharu 0 siblings, 2 replies; 40+ messages in thread From: Eli Zaretskii @ 2015-12-04 9:47 UTC (permalink / raw) To: martin rudalics; +Cc: yuan.mei.list, emacs-devel > Date: Fri, 04 Dec 2015 10:05:14 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org> > > > Without cairo: > > > > 17 (#o21, #x11, ?\C-q) > > > > With cairo: > > > > 16 (#o20, #x10, ?\C-p) > > So it's the Cairo font backend. 59 text lines plus one menu bar line > give the 60 pixels difference. I don't understand how can it do that with the same size of the same font. Some bug in ftcrfont.c, perhaps? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 9:47 ` Eli Zaretskii @ 2015-12-04 10:21 ` martin rudalics 2015-12-04 11:01 ` Eli Zaretskii 2015-12-05 0:25 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 40+ messages in thread From: martin rudalics @ 2015-12-04 10:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: yuan.mei.list, emacs-devel >> So it's the Cairo font backend. 59 text lines plus one menu bar line >> give the 60 pixels difference. > > I don't understand how can it do that with the same size of the same > font. Some bug in ftcrfont.c, perhaps? Do what? Yuan Mei initially told us: >> And I noticed something: comparing with and without cairo, even though >> the number of lines of text and other geometric parameters are >> identical (no .Xdefaults or any changes in .emacs.d/, the window >> (frame) height for with and without cairo are different. Something >> about font handling are different? When creating a frame, its height is determined by multiplying the number of lines specified in ‘default-frame-alist’ by its default font height. martin ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 10:21 ` martin rudalics @ 2015-12-04 11:01 ` Eli Zaretskii 2015-12-04 11:12 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-12-04 11:01 UTC (permalink / raw) To: martin rudalics; +Cc: yuan.mei.list, emacs-devel > Date: Fri, 04 Dec 2015 11:21:57 +0100 > From: martin rudalics <rudalics@gmx.at> > CC: yuan.mei.list@gmail.com, emacs-devel@gnu.org > > >> So it's the Cairo font backend. 59 text lines plus one menu bar line > >> give the 60 pixels difference. > > > > I don't understand how can it do that with the same size of the same > > font. Some bug in ftcrfont.c, perhaps? > > Do what? Compute a different frame-char-height for the same font and font size. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 11:01 ` Eli Zaretskii @ 2015-12-04 11:12 ` Eli Zaretskii 0 siblings, 0 replies; 40+ messages in thread From: Eli Zaretskii @ 2015-12-04 11:12 UTC (permalink / raw) To: rudalics; +Cc: yuan.mei.list, emacs-devel > Date: Fri, 04 Dec 2015 13:01:31 +0200 > Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and > truncated. > From: Eli Zaretskii <eliz@gnu.org> > Cc: yuan.mei.list@gmail.com, emacs-devel@gnu.org > > > Date: Fri, 04 Dec 2015 11:21:57 +0100 > > From: martin rudalics <rudalics@gmx.at> > > CC: yuan.mei.list@gmail.com, emacs-devel@gnu.org > > > > >> So it's the Cairo font backend. 59 text lines plus one menu bar line > > >> give the 60 pixels difference. > > > > > > I don't understand how can it do that with the same size of the same > > > font. Some bug in ftcrfont.c, perhaps? > > > > Do what? > > Compute a different frame-char-height for the same font and font size. In case this is not clear: xterm.c computes FRAME_LINE_HEIGHT as follows: get_font_ascent_descent (font, &font_ascent, &font_descent); FRAME_LINE_HEIGHT (f) = font_ascent + font_descent; So the result comes from 2 values determined only by the frame's default font. These values are returned by the font back-end that accesses the font, so only the font back-end could have affected them for the same font. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-04 9:47 ` Eli Zaretskii 2015-12-04 10:21 ` martin rudalics @ 2015-12-05 0:25 ` YAMAMOTO Mitsuharu 2015-12-05 9:17 ` Eli Zaretskii 1 sibling, 1 reply; 40+ messages in thread From: YAMAMOTO Mitsuharu @ 2015-12-05 0:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: yuan.mei.list, martin rudalics, emacs-devel >>>>> On Fri, 04 Dec 2015 11:47:23 +0200, Eli Zaretskii <eliz@gnu.org> said: >> Date: Fri, 04 Dec 2015 10:05:14 +0100 >> From: martin rudalics <rudalics@gmx.at> >> CC: Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org> >> >> > Without cairo: >> > >> > 17 (#o21, #x11, ?\C-q) >> > >> > With cairo: >> > >> > 16 (#o20, #x10, ?\C-p) >> >> So it's the Cairo font backend. 59 text lines plus one menu bar line >> give the 60 pixels difference. > I don't understand how can it do that with the same size of the same > font. Some bug in ftcrfont.c, perhaps? Maybe one font backend rounds the fractional metrics values but the other truncates them? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp diff --git a/src/ftfont.c b/src/ftfont.c index 17e41a9..c10d4ad 100644 --- a/src/ftfont.c +++ b/src/ftfont.c @@ -1159,6 +1159,12 @@ ftfont_list_family (struct frame *f) } +/* Operators for 26.6 fixed fractional pixel format */ + +#define FLOOR(x) ((x) & -64) +#define CEIL(x) (((x)+63) & -64) +#define ROUND(x) (((x)+32) & -64) + Lisp_Object ftfont_open2 (struct frame *f, Lisp_Object entity, @@ -1237,9 +1243,9 @@ ftfont_open2 (struct frame *f, } else { - font->ascent = ft_face->size->metrics.ascender >> 6; - font->descent = - ft_face->size->metrics.descender >> 6; - font->height = ft_face->size->metrics.height >> 6; + font->ascent = ROUND (ft_face->size->metrics.ascender) >> 6; + font->descent = - ROUND (ft_face->size->metrics.descender) >> 6; + font->height = ROUND (ft_face->size->metrics.height) >> 6; } if (INTEGERP (AREF (entity, FONT_SPACING_INDEX))) spacing = XINT (AREF (entity, FONT_SPACING_INDEX)); @@ -1252,7 +1258,7 @@ ftfont_open2 (struct frame *f, ) font->min_width = font->average_width = font->space_width = (scalable ? ft_face->max_advance_width * size / upEM + 0.5 - : ft_face->size->metrics.max_advance >> 6); + : ROUND (ft_face->size->metrics.max_advance) >> 6); else { int n; @@ -1261,7 +1267,7 @@ ftfont_open2 (struct frame *f, for (i = 32, n = 0; i < 127; i++) if (FT_Load_Char (ft_face, i, FT_LOAD_DEFAULT) == 0) { - int this_width = ft_face->glyph->metrics.horiAdvance >> 6; + int this_width = ROUND (ft_face->glyph->metrics.horiAdvance) >> 6; if (this_width > 0 && (! font->min_width || font->min_width > this_width)) @@ -1601,12 +1607,6 @@ ftfont_get_glyph_id (MFLTFont *font, MFLTGlyphString *gstring, return 0; } -/* Operators for 26.6 fixed fractional pixel format */ - -#define FLOOR(x) ((x) & -64) -#define CEIL(x) (((x)+63) & -64) -#define ROUND(x) (((x)+32) & -64) - static int ftfont_get_metrics (MFLTFont *font, MFLTGlyphString *gstring, int from, int to) ^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-05 0:25 ` YAMAMOTO Mitsuharu @ 2015-12-05 9:17 ` Eli Zaretskii 2015-12-06 0:49 ` Yuan MEI 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-12-05 9:17 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: yuan.mei.list, rudalics, emacs-devel > Date: Sat, 05 Dec 2015 09:25:46 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: martin rudalics <rudalics@gmx.at>, > yuan.mei.list@gmail.com, > emacs-devel@gnu.org > > >>>>> On Fri, 04 Dec 2015 11:47:23 +0200, Eli Zaretskii <eliz@gnu.org> said: > > >> Date: Fri, 04 Dec 2015 10:05:14 +0100 > >> From: martin rudalics <rudalics@gmx.at> > >> CC: Eli Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org> > >> > >> > Without cairo: > >> > > >> > 17 (#o21, #x11, ?\C-q) > >> > > >> > With cairo: > >> > > >> > 16 (#o20, #x10, ?\C-p) > >> > >> So it's the Cairo font backend. 59 text lines plus one menu bar line > >> give the 60 pixels difference. > > > I don't understand how can it do that with the same size of the same > > font. Some bug in ftcrfont.c, perhaps? > > Maybe one font backend rounds the fractional metrics values but the > other truncates them? Could be. Yuan, could you try these changes, and see if the dimensions of the Cairo frame become identical to that of the non-Cairo build? Thanks. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-05 9:17 ` Eli Zaretskii @ 2015-12-06 0:49 ` Yuan MEI 2015-12-07 3:33 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 40+ messages in thread From: Yuan MEI @ 2015-12-06 0:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: martin rudalics, YAMAMOTO Mitsuharu, emacs-devel >> Maybe one font backend rounds the fractional metrics values but the >> other truncates them? > > Could be. Yuan, could you try these changes, and see if the > dimensions of the Cairo frame become identical to that of the > non-Cairo build? I tried the patch. However Cairo frame and non-Cairo frame still differ by the same amount as reported before. Yuan ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-06 0:49 ` Yuan MEI @ 2015-12-07 3:33 ` YAMAMOTO Mitsuharu 2015-12-07 17:19 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: YAMAMOTO Mitsuharu @ 2015-12-07 3:33 UTC (permalink / raw) To: Yuan MEI; +Cc: martin rudalics, Eli Zaretskii, emacs-devel >>>>> On Sat, 5 Dec 2015 16:49:29 -0800, Yuan MEI <yuan.mei.list@gmail.com> said: >>> Maybe one font backend rounds the fractional metrics values but >>> the other truncates them? >> >> Could be. Yuan, could you try these changes, and see if the >> dimensions of the Cairo frame become identical to that of the >> non-Cairo build? > I tried the patch. However Cairo frame and non-Cairo frame still > differ by the same amount as reported before. So, rounding has nothing to do with the difference you observe. It seems that freetype has two types of structures containing metrics values (ascender, descender, height): FT_FaceRec and FT_Size_Metrics. ftfont.c uses the former for scalable fonts and the latter for the other cases. ftfont.c in Emacs: if (scalable) { font->ascent = ft_face->ascender * size / upEM + 0.5; font->descent = - ft_face->descender * size / upEM + 0.5; font->height = ft_face->height * size / upEM + 0.5; } else { font->ascent = ft_face->size->metrics.ascender >> 6; font->descent = - ft_face->size->metrics.descender >> 6; font->height = ft_face->size->metrics.height >> 6; } libXft internally uses the latter only. xftfreetype.c in libXft: if (fi->transform) { /* snip */ } else { descent = -(face->size->metrics.descender >> 6); ascent = face->size->metrics.ascender >> 6; if (fi->minspace) height = ascent + descent; else height = face->size->metrics.height >> 6; } font->public.ascent = ascent; font->public.descent = descent; font->public.height = height; I don't know which is correct/appropriate. At least, there is a case that these two kinds of values are different. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-07 3:33 ` YAMAMOTO Mitsuharu @ 2015-12-07 17:19 ` Eli Zaretskii 2015-12-08 4:03 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 40+ messages in thread From: Eli Zaretskii @ 2015-12-07 17:19 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: yuan.mei.list, rudalics, emacs-devel > Date: Mon, 07 Dec 2015 12:33:22 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: Eli Zaretskii <eliz@gnu.org>, > martin rudalics <rudalics@gmx.at>, > emacs-devel <emacs-devel@gnu.org> > > > I tried the patch. However Cairo frame and non-Cairo frame still > > differ by the same amount as reported before. > > So, rounding has nothing to do with the difference you observe. > > It seems that freetype has two types of structures containing metrics > values (ascender, descender, height): FT_FaceRec and FT_Size_Metrics. > ftfont.c uses the former for scalable fonts and the latter for the > other cases. Perhaps Yuan could look at the respective values in the debugger, and see if they explain the 1-pixel difference. Can you suggest to him how to set up his debugging session so as to catch the values for the default font? Thanks. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-07 17:19 ` Eli Zaretskii @ 2015-12-08 4:03 ` YAMAMOTO Mitsuharu 2015-12-11 8:48 ` Eli Zaretskii 0 siblings, 1 reply; 40+ messages in thread From: YAMAMOTO Mitsuharu @ 2015-12-08 4:03 UTC (permalink / raw) To: Eli Zaretskii; +Cc: yuan.mei.list, rudalics, emacs-devel >>>>> On Mon, 07 Dec 2015 19:19:48 +0200, Eli Zaretskii <eliz@gnu.org> said: >> It seems that freetype has two types of structures containing >> metrics values (ascender, descender, height): FT_FaceRec and >> FT_Size_Metrics. ftfont.c uses the former for scalable fonts and >> the latter for the other cases. > Perhaps Yuan could look at the respective values in the debugger, > and see if they explain the 1-pixel difference. Can you suggest to > him how to set up his debugging session so as to catch the values > for the default font? I assume you are using the emacs-25 branch. (undo my previous patch) % make clean % make CFLAGS='-O0 -g3' % gdb src/emacs (gdb) b ftfont.c:1244 (gdb) command >call (void)debug_print(entity) >p scalable >p *ft_face >p ft_face->size.metrics >cont >end (gdb) r YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-12-08 4:03 ` YAMAMOTO Mitsuharu @ 2015-12-11 8:48 ` Eli Zaretskii 0 siblings, 0 replies; 40+ messages in thread From: Eli Zaretskii @ 2015-12-11 8:48 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: yuan.mei.list, rudalics, emacs-devel > Date: Tue, 08 Dec 2015 13:03:19 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: yuan.mei.list@gmail.com, > rudalics@gmx.at, > emacs-devel@gnu.org > > >>>>> On Mon, 07 Dec 2015 19:19:48 +0200, Eli Zaretskii <eliz@gnu.org> said: > > >> It seems that freetype has two types of structures containing > >> metrics values (ascender, descender, height): FT_FaceRec and > >> FT_Size_Metrics. ftfont.c uses the former for scalable fonts and > >> the latter for the other cases. > > > Perhaps Yuan could look at the respective values in the debugger, > > and see if they explain the 1-pixel difference. Can you suggest to > > him how to set up his debugging session so as to catch the values > > for the default font? > > I assume you are using the emacs-25 branch. > > (undo my previous patch) > % make clean > % make CFLAGS='-O0 -g3' > % gdb src/emacs > (gdb) b ftfont.c:1244 > (gdb) command > >call (void)debug_print(entity) > >p scalable > >p *ft_face > >p ft_face->size.metrics > >cont > >end > (gdb) r Thanks. Yuan, could you please do this and report the results? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-28 8:06 ` Eli Zaretskii 2015-11-28 8:27 ` Yuan MEI @ 2015-11-28 21:44 ` joakim 2015-11-29 0:14 ` Yuan MEI 1 sibling, 1 reply; 40+ messages in thread From: joakim @ 2015-11-28 21:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Yuan MEI, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> Date: Fri, 27 Nov 2015 14:31:55 -0800 >> From: Yuan MEI <yuan.mei.list@gmail.com> >> >> Sometimes when I switch to another virtual desktop then come back >> to emacs > > What is a "virtual desktop" in this case? > >> the entire frame shows only the background color, no letter >> or only part of the frame is visible. This does not happen all the >> time though. I just happened to capture a screenshot (attached, I >> hope the mailing server accepts it.) > > The screenshot shows a text-mode Emacs frame, AFAICT. Does this > happen only with text-mode frames, or do you see that in GUI frames as > well? > > If this happens with text-mode frames only, then that's not an Emacs > problem. It's a problem with the terminal emulator (xterm etc.) you > are using: it should sense the switch and redraw the display on the > low level. > > When Emacs runs on a TTY, it doesn't listen to any expose or conceal > messages sent by the windowing system, so it has no idea that its > display was concealed or exposed, and cannot initiate a redisplay in > these situations. From the Emacs POV, a TTY frame is the only thing > displayed by the console device, and the only way such a frame can be > concealed and exposed is by stopping Emacs (with the likes of "C-z") > and then resuming it. And these are the only cases a TTY frame will > be completely redrawn. > > GUI frames are different: Emacs gets expose events for them, and > should react by redrawing the exposed portion(s) of the frame. > FWIW I have also been experiencing redrawing issues lately. I have believed this was some problem with my desktop remoting software, x2go, but I'm beginning to suspect Emacs has some issue. I have used x2go and emacs for years with no problems whatsoever, but I can't rule out recent upgrades of my operating system as the source of my problem. I think I run the same window manager as Yuan as well. -- Joakim Verona ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Redisplay issue 2015-11-28 21:44 ` joakim @ 2015-11-29 0:14 ` Yuan MEI 0 siblings, 0 replies; 40+ messages in thread From: Yuan MEI @ 2015-11-29 0:14 UTC (permalink / raw) To: joakim; +Cc: Eli Zaretskii, emacs-devel > FWIW I have also been experiencing redrawing issues lately. > I have believed this was some problem with my desktop remoting software, > x2go, but I'm beginning to suspect Emacs has some issue. > > I have used x2go and emacs for years with no problems whatsoever, but I > can't rule out recent upgrades of my operating system as the source of > my problem. > > I think I run the same window manager as Yuan as well. I am running Fvwm-2.6.5 on xorg-server-1.16.4 natively and locally. ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2015-12-11 8:48 UTC | newest] Thread overview: 40+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-11-27 22:31 Redisplay issue Yuan MEI 2015-11-28 8:06 ` Eli Zaretskii 2015-11-28 8:27 ` Yuan MEI 2015-11-28 9:44 ` Eli Zaretskii 2015-11-28 20:19 ` Yuan MEI 2015-11-28 20:49 ` Eli Zaretskii 2015-11-29 2:54 ` Yuan MEI 2015-11-29 15:42 ` Eli Zaretskii 2015-11-29 23:35 ` Yuan MEI 2015-11-30 16:16 ` Eli Zaretskii 2015-12-01 4:51 ` Yuan MEI 2015-12-01 16:01 ` Eli Zaretskii 2015-12-02 4:35 ` Yuan MEI 2015-12-02 13:57 ` Eli Zaretskii 2015-12-03 4:55 ` Yuan MEI 2015-12-03 7:47 ` Eli Zaretskii 2015-12-03 8:09 ` Yuan MEI 2015-12-03 10:23 ` Eli Zaretskii 2015-12-03 18:16 ` martin rudalics 2015-12-03 21:23 ` Yuan MEI 2015-12-04 8:08 ` martin rudalics 2015-12-04 8:30 ` Yuan MEI 2015-12-04 8:48 ` martin rudalics 2015-12-04 8:54 ` Yuan MEI 2015-12-04 8:56 ` martin rudalics 2015-12-04 9:00 ` Yuan MEI 2015-12-04 9:05 ` martin rudalics 2015-12-04 9:47 ` Eli Zaretskii 2015-12-04 10:21 ` martin rudalics 2015-12-04 11:01 ` Eli Zaretskii 2015-12-04 11:12 ` Eli Zaretskii 2015-12-05 0:25 ` YAMAMOTO Mitsuharu 2015-12-05 9:17 ` Eli Zaretskii 2015-12-06 0:49 ` Yuan MEI 2015-12-07 3:33 ` YAMAMOTO Mitsuharu 2015-12-07 17:19 ` Eli Zaretskii 2015-12-08 4:03 ` YAMAMOTO Mitsuharu 2015-12-11 8:48 ` Eli Zaretskii 2015-11-28 21:44 ` joakim 2015-11-29 0:14 ` Yuan MEI
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.