Redisplay issue

Redisplay issue

[Yuan MEI]

[-- 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 --]

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[Yuan MEI]

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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[Yuan MEI]

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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[joakim]

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

Re: Redisplay issue

[Yuan MEI]

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

Re: Redisplay issue

[Yuan MEI]

[-- 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 --]

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[Yuan MEI]

> 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

Re: Redisplay issue

[Eli Zaretskii]

> 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;
 	}

Re: Redisplay issue

[Yuan MEI]

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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[Yuan MEI]

> 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

Re: Redisplay issue

[Eli Zaretskii]

> 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 ();
 }
 
 

Re: Redisplay issue

[Yuan MEI]

> 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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[Yuan MEI]

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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[martin rudalics]

 > 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

Re: Redisplay issue

[Yuan MEI]

[-- 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 --]

Re: Redisplay issue

[martin rudalics]

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

Re: Redisplay issue

[Yuan MEI]

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

Re: Redisplay issue

[martin rudalics]

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

Re: Redisplay issue

[Yuan MEI]

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

Re: Redisplay issue

[martin rudalics]

 > 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

Re: Redisplay issue

[Yuan MEI]

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

Re: Redisplay issue

[martin rudalics]

 > 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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[martin rudalics]

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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[YAMAMOTO Mitsuharu]

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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[Yuan MEI]

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

Re: Redisplay issue

[YAMAMOTO Mitsuharu]

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

Re: Redisplay issue

[Eli Zaretskii]

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

Re: Redisplay issue

[YAMAMOTO Mitsuharu]

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

Re: Redisplay issue

[Eli Zaretskii]

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