bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

In the following single-headed setup GNU Emacs behaves as intended:

  Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
  VGA1 connected primary (normal left inverted right x axis y axis)
     1280x720      59.86 +
     1024x768      75.08    70.07    60.00
     832x624       74.55
     800x600       72.19    75.00    60.32    56.25
     640x480       75.00    72.81    66.67    60.00
     720x400       70.08
  LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y
axis) 228mm x 131mm
     1024x600      59.99*+
     800x600       60.32    56.25
     640x480       59.94

In this setup, as you can see, only the LVDS1 output is enabled.

However in my usual setup I have both outputs enabled for a dual-headed
display:

  Screen 0: minimum 320 x 200, current 2304 x 720, maximum 4096 x 4096
  VGA1 connected primary 1280x720+0+0 (normal left inverted right x axis
y axis) 340mm x 270mm
     1280x720      59.86*+
     1024x768      75.08    70.07    60.00
     832x624       74.55
     800x600       72.19    75.00    60.32    56.25
     640x480       75.00    72.81    66.67    60.00
     720x400       70.08
  LVDS1 connected 1024x600+1280+120 (normal left inverted right x axis y
axis) 228mm x 131mm
     1024x600      59.99*+
     800x600       60.32    56.25
     640x480       59.94

In this setup GNU Emacs corrupts the mode-line (a graphical glitch)
drawing over it the buffer's line that would otherwise be below it.

Refreshing the window with 'xrefresh' or just switching to another
window and back again repaints the mode-line content, so it looks
normal, until the next buffer scroll operation, when it gets corrupt
again.

Starting Emacs with the '-Q' option, without changing the frame's
geometry, and typing 'C-x d /dev <RET>' is sufficient to reproduce the
bug.  Actually, most of the time, Emacs windows that hold text
underneath the mode-line trigger the problem.

See the attached screenshot for how the corrupted mode-line looks like.




In GNU Emacs 24.4.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2014-10-30 on felix-laptop
Windowing system distributor `The X.Org Foundation', version 11.0.11601000
System Description:	Debian GNU/Linux testing (jessie)

Configured using:
 `configure --prefix=/home/felix/opt/emacs-24.4 --with-x-toolkit=athena'

Important settings:
  value of $LANG: pt_BR.utf8
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-scheduler-mode: t
  semantic-mode: t
  winner-mode: t
  electric-pair-mode: t
  show-paren-mode: t
  display-time-mode: t
  which-function-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail reposition calc-alg calc-ext
calc-menu calc calc-loaddefs calc-macs crm org org-macro org-footnote
org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp
ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint
ob-core ob-eval org-compat org-macs org-loaddefs debbugs-gnu derived
debbugs cl-macs cl soap-client warnings xml diff-mode diff autoload
tar-mode lisp-mnt mm-archive message format-spec rfc822 mml mml-sec
mailabbrev gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils
network-stream starttls url-http tls mail-parse rfc2231 rfc2047 rfc2045
ietf-drums url-gw url-cache url-auth url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap url-handlers url-parse auth-source gnus-util mm-util mail-prsvr
password-cache url-vars epg finder-inf browse-url goto-addr shell
pcomplete grep compile dired-aux dired dabbrev cus-edit wid-edit
cus-start cus-load noutline outline view apropos gdb-mi bindat json gud
easy-mmode comint ansi-color linum mule-util cal-move cal-menu calendar
cal-loaddefs semantic/tag-write jka-compr misearch multi-isearch
semantic/symref/list semantic/complete eieio-opt semantic/sb speedbar
sb-image dframe find-func semantic/symref semantic/analyze/complete
semantic/db-typecache semantic/ia semantic/senator semantic/edit
help-mode thingatpt semantic/tag-file add-log semantic/imenu advice
semantic/db-file data-debug cedet-files semantic/bovine/c
semantic/decorate/include semantic/decorate/mode semantic/decorate pulse
hideif semantic/bovine/c-by semantic/lex-spp semantic/bovine/gcc
semantic/dep semantic/bovine semantic/analyze/refs semantic/db-find
semantic/db-ref semantic/analyze semantic/sort semantic/scope
semantic/analyze/fcn superword subword cc-langs cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
server eldoc help-fns paredit hideshow glasses flyspell ispell
semantic/db-mode semantic/db gv eieio-base semantic/idle semantic/format
ezimage semantic/tag-ls semantic/find semantic/ctxt semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw eieio
byte-opt bytecomp byte-compile cconv eieio-core mode-local cedet
windmove winner ring elec-pair paren time time-date which-func imenu
edmacro kmacro cl-loaddefs cl-lib auctex-autoloads company-autoloads
dired-details+-autoloads dired-details-autoloads info easymenu
geiser-autoloads google-translate-autoloads paredit-autoloads
quack-autoloads sokoban-autoloads package epg-config tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer 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 make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty emacs)

Memory information:
((conses 8 474862 160898)
 (symbols 24 44010 0)
 (miscs 20 6276 2576)
 (strings 16 101774 31471)
 (string-bytes 1 2940699)
 (vectors 8 39166)
 (vector-slots 4 725772 24178)
 (floats 8 2008 461)
 (intervals 28 12998 46)
 (buffers 512 38)
 (heap 1024 53384 2385))

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;

[-- Attachment #1.2: emacs-mode-line-bug.png --]
[-- Type: image/png, Size: 82197 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Stefan Monnier]

> In this setup GNU Emacs corrupts the mode-line (a graphical glitch)
> drawing over it the buffer's line that would otherwise be below it.

My guess is that it's a bug in the X11 acceleration code for your
graphics card.  At least, that was the conclusion the last time this
came up, IIRC.


        Stefan

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Stefan Monnier wrote:
> My guess is that it's a bug in the X11 acceleration code for your
> graphics card.  At least, that was the conclusion the last time this
> came up, IIRC.

FWIW, my X11 graphics card driver is 'intel' and my card is an 'Intel
945 GME'.

What about an Emacs workaround: redraw the mode-line after any scroll
operation? :-P

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 31 Oct 2014 16:30:18 -0400
> Cc: 18912@debbugs.gnu.org
> 
> > In this setup GNU Emacs corrupts the mode-line (a graphical glitch)
> > drawing over it the buffer's line that would otherwise be below it.
> 
> My guess is that it's a bug in the X11 acceleration code for your
> graphics card.

How could the graphics card "know" the details of the file that should
not be visible in the window?  The text that overwrites the mode line
is not for any of the files shown above the mode line, it's the file
that is the next one in the listing.  So the only way the acceleration
could cause that is if it returned incorrect information about the
display dimensions/pixel size.  I cannot explain to myself how this
kind of bug in the graphics card could affect Emacs, except perhaps in
a maximized frame.

Bruno, do these problems happen in a non-maximized frame, e.g. the one
you get immediately after invoking "emacs -Q"?

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> Bruno, do these problems happen in a non-maximized frame, e.g. the one
> you get immediately after invoking "emacs -Q"?

Yes, they do.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Thu, 30 Oct 2014 11:46:29 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> 
> 
> [1:multipart/mixed Hide]
> 
> 
> [1/1:text/plain Hide]
> 
> In the following single-headed setup GNU Emacs behaves as intended:
> 
>   Screen 0: minimum 320 x 200, current 1024 x 600, maximum 4096 x 4096
>   VGA1 connected primary (normal left inverted right x axis y axis)
>      1280x720      59.86 +
>      1024x768      75.08    70.07    60.00
>      832x624       74.55
>      800x600       72.19    75.00    60.32    56.25
>      640x480       75.00    72.81    66.67    60.00
>      720x400       70.08
>   LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y
> axis) 228mm x 131mm
>      1024x600      59.99*+
>      800x600       60.32    56.25
>      640x480       59.94
> 
> In this setup, as you can see, only the LVDS1 output is enabled.
> 
> However in my usual setup I have both outputs enabled for a dual-headed
> display:
> 
>   Screen 0: minimum 320 x 200, current 2304 x 720, maximum 4096 x 4096
>   VGA1 connected primary 1280x720+0+0 (normal left inverted right x axis
> y axis) 340mm x 270mm
>      1280x720      59.86*+
>      1024x768      75.08    70.07    60.00
>      832x624       74.55
>      800x600       72.19    75.00    60.32    56.25
>      640x480       75.00    72.81    66.67    60.00
>      720x400       70.08
>   LVDS1 connected 1024x600+1280+120 (normal left inverted right x axis y
> axis) 228mm x 131mm
>      1024x600      59.99*+
>      800x600       60.32    56.25
>      640x480       59.94
> 
> In this setup GNU Emacs corrupts the mode-line (a graphical glitch)
> drawing over it the buffer's line that would otherwise be below it.
> 
> Refreshing the window with 'xrefresh' or just switching to another
> window and back again repaints the mode-line content, so it looks
> normal, until the next buffer scroll operation, when it gets corrupt
> again.
> 
> Starting Emacs with the '-Q' option, without changing the frame's
> geometry, and typing 'C-x d /dev <RET>' is sufficient to reproduce the
> bug.  Actually, most of the time, Emacs windows that hold text
> underneath the mode-line trigger the problem.

Please show the output of each one the following forms, evaluated in
both the "good" and "bad" configurations, when you start "emacs -Q"
and visit the same /dev directory:

  (window-height)
  (window-pixel-height)

You can evaluate each form using M-:, as in

  M-: ((window-height) RET

Please compare the return value of window-height with the actual
number of lines available in that window, and tell if the two match.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Sat, 01 Nov 2014 10:38:12 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18912@debbugs.gnu.org
> 
> You can evaluate each form using M-:, as in
> 
>   M-: ((window-height) RET

Sorry, please use just one opening parenthesis:

  M-: (window-height) RET

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> Please show the output of each one the following forms, evaluated in
> both the "good" and "bad" configurations, when you start "emacs -Q"
> and visit the same /dev directory:
> 
>   (window-height)
>   (window-pixel-height)
> 
> You can evaluate each form using M-:, as in
> 
>   M-: (window-height) RET
> 
> Please compare the return value of window-height with the actual
> number of lines available in that window, and tell if the two match.

For this test Emacs was started with the option '-Q' and in both
configurations the frame was put by the window manager in the same area
of the VGA1 output, with unchanged relative geometry:

  xwininfo (common to both configurations):
    Absolute upper-left X:  520
    Absolute upper-left Y:  23
    Relative upper-left X:  4
    Relative upper-left Y:  23
    Width: 756
    Height: 697
    Depth: 24
    Border width: 0

Good configuration (only VGA1 enabled):

  xwininfo:
    Corners:  +520+23  -4+23  -4-0  +520-0
    -geometry 80x37-0+0

  (window-height) => 34
  (window-pixel-height) => 612

Bad configuration (both VGA1 and LVDS1 enabled):

  xwininfo:
    Corners:  +520+23  -1028+23  -1028-0  +520-0
    -geometry 80x37+516+0

  (window-height) ==> 34
  (window-pixel-height) ==> 613

Interesting enough, '(window-pixel-height)' returns different values for
both configurations under the "same" circumstances.  Furthermore, in
both configurations '(window-height)' returns one line more than what
was actually shown.  Therefore, both expressions seem to suggest an "off
by one" bug.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Sat, 01 Nov 2014 10:54:03 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> For this test Emacs was started with the option '-Q' and in both
> configurations the frame was put by the window manager in the same area
> of the VGA1 output, with unchanged relative geometry:
> 
>   xwininfo (common to both configurations):
>     Absolute upper-left X:  520
>     Absolute upper-left Y:  23
>     Relative upper-left X:  4
>     Relative upper-left Y:  23
>     Width: 756
>     Height: 697
>     Depth: 24
>     Border width: 0
> 
> Good configuration (only VGA1 enabled):
> 
>   xwininfo:
>     Corners:  +520+23  -4+23  -4-0  +520-0
>     -geometry 80x37-0+0
> 
>   (window-height) => 34
>   (window-pixel-height) => 612
> 
> Bad configuration (both VGA1 and LVDS1 enabled):
> 
>   xwininfo:
>     Corners:  +520+23  -1028+23  -1028-0  +520-0
>     -geometry 80x37+516+0
> 
>   (window-height) ==> 34
>   (window-pixel-height) ==> 613

Thanks.

I don't see anything strange here, the 1-pixel difference shouldn't
have caused what you see.

Martin, any suggestions how to dig into this further?

> Interesting enough, '(window-pixel-height)' returns different values for
> both configurations under the "same" circumstances.  Furthermore, in
> both configurations '(window-height)' returns one line more than what
> was actually shown.  Therefore, both expressions seem to suggest an "off
> by one" bug.

I see no bug here: both functions return the height of the window
including the mode line, so the value sounds correct if you have 33
lines of text in that window.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> Thanks.
> 
> I don't see anything strange here, the 1-pixel difference shouldn't
> have caused what you see.
> 
> Martin, any suggestions how to dig into this further?

What about implementing a global variable
'refresh-mode-line-after-scroll' which when set to 't' repaints the
mode-line after any scroll operation?  While it'd be just a workaround
treating the symptoms rather than the actual cause, it would be handy to
solve a whole class of problems, some potentially very hard to reproduce
and therefore fix, which would result in this same unwanted side effect
of corrupting the mode-line.  If the workaround is good enough, it can
possibly save Emacs developers time in the future, if the users are
happy sticking with it.  I'd be happy, BTW.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Sun, 02 Nov 2014 19:49:50 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> What about implementing a global variable
> 'refresh-mode-line-after-scroll' which when set to 't' repaints the
> mode-line after any scroll operation?

Unnecessary redrawing causes unpleasant flickering that people
rightfully complain about.

Emacs never writes buffer contents where the mode line should be, so
this problem could only happen if Emacs for some reason becomes
confused about the window dimensions.  The result could be a variety
of display problems, not just what you see.

Are you willing to debug this problem on your machine using GDB?  If
so, I might come up with some instructions.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> Unnecessary redrawing causes unpleasant flickering that people
> rightfully complain about.

It wouldn't be unnecessary because only people having a similar problem
would deliberately enable the mode-line redrawing.  I can assure you a
constantly corrupted mode-line is much more annoying than one fast flash
that will only occur sporadically, in just one line, by direct command
of the user.  In particular, on scroll operations all lines in the
window are expected to change, so it's not that bad if just one more
line, contiguous to the region, flashes.  Actually, the chances are that
the flash won't be noticeable at all.

As suggested, this workaround would have no effect on any users that
have not experienced the problem, while virtually fixing it for people
who experiences it.  That's almost ideal in a scenario where it'd be
very time consuming or hard to find the cause and fix the actual bug.

> Emacs never writes buffer contents where the mode line should be, so
> this problem could only happen if Emacs for some reason becomes
> confused about the window dimensions.  The result could be a variety
> of display problems, not just what you see.

Yeah, it might be, but we can't really know until someone experiences
other correlated display problems.  However, the workaround won't worsen
the bug under any possible circumstances, and fixes it for people who
are already experiencing that particular display problem.

> Are you willing to debug this problem on your machine using GDB?  If
> so, I might come up with some instructions.

Sure, why not?  However, if we can't find the bug's root, I'll ask you
to consider implementing the suggested workaround.  Deal? ;-)

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Mon, 03 Nov 2014 04:03:39 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: rudalics@gmx.at, 18912@debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > Unnecessary redrawing causes unpleasant flickering that people
> > rightfully complain about.
> 
> It wouldn't be unnecessary because only people having a similar problem
> would deliberately enable the mode-line redrawing.  I can assure you a
> constantly corrupted mode-line is much more annoying than one fast flash
> that will only occur sporadically, in just one line, by direct command
> of the user.  In particular, on scroll operations all lines in the
> window are expected to change, so it's not that bad if just one more
> line, contiguous to the region, flashes.  Actually, the chances are that
> the flash won't be noticeable at all.

I'd like to solve this problem, not paper over it.  I hope you agree
that solving it is better than working around it.

> > Are you willing to debug this problem on your machine using GDB?  If
> > so, I might come up with some instructions.
> 
> Sure, why not?

Thanks, please find the instructions below.

> However, if we can't find the bug's root, I'll ask you to consider
> implementing the suggested workaround.  Deal? ;-)

I find it hard to believe that we won't find the root cause, so I
think we don't need to consider that possibility.

Here are the first instructions to get information that will help us
start digging into this.  (These are in addition to what Martin
already requested.)

First, please build Emacs without optimizations and with extra
checking code enabled:

  CFLAGS='-O0 -g3' ./configure --prefix=/home/felix/opt/emacs-24.4 --with-x-toolkit=athena --enable-checking='yes,glyphs'

(I only care about CFLAGS and the --enable-checking= option; the rest
I just copied from your original report, but feel free to change them
if you want.  The --enable-checking= option is required to compile the
dump-glyph-matrix command I ask you to use below.)

After 'configure' finishes, invoke "make".  You don't have to invoke
"make install", as Emacs can be run from the src/ directory where it
was built.

Now start Emacs you've just build with "emacs -Q", type the "C-x d"
command that you say is sufficient to reproduce the problem, and then
type this:

  M-x dump-glyph-matrix RET

This outputs to the standard error stream the description of the
internal data structure, called "glyph matrix", which Emacs maintains
for each window on a GUI frame.  Please post that output (you may wish
to redirect stderr to a file when you invoke Emacs, to make that
easier).

Please do this once for the "good" configuration, and another time for
the "bad" configuration, but please make sure you invoke Emacs the
same in both cases and type the same "C-x d" command in each case.

Next, in the "bad" configuration and with the listing of /dev and
corrupted mode line displayed, type this:

  M-: (setq frame-resize-pixelwise t) RET

Now carefully decrease the frame's height by dragging its upper or
lower edge with the mouse.  Please drag it slowly and carefully, so
that the frame is resized one pixel at a time.  After each resize,
please see if the mode line is no longer corrupted.  Perhaps kill the
buffer and type "C-x d" again to make sure the corruption disappeared
for good.  The first time the mode line stops being corrupted, type

  M-x dump-glyph-matrix RET

again, and include this (3rd) output in your message.  Also, please
tell how many pixels did you subtract from the original frame height
before the corruption disappeared (assuming it ever does).

Where are the instructions to use the debugger, you ask?  Well, not
yet, but maybe after we see what the above tells us.

Thanks.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[martin rudalics]

 > Now carefully decrease the frame's height by dragging its upper or
 > lower edge with the mouse.  Please drag it slowly and carefully, so
 > that the frame is resized one pixel at a time.  After each resize,
 > please see if the mode line is no longer corrupted.

Is there any reason Bruno cannot use something like

(while (y-or-n-p "decrease?")
   (set-frame-height nil (1- (frame-text-height)) nil t))

here?

martin

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Mon, 03 Nov 2014 18:43:38 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 18912@debbugs.gnu.org
> 
>  > Now carefully decrease the frame's height by dragging its upper or
>  > lower edge with the mouse.  Please drag it slowly and carefully, so
>  > that the frame is resized one pixel at a time.  After each resize,
>  > please see if the mode line is no longer corrupted.
> 
> Is there any reason Bruno cannot use something like
> 
> (while (y-or-n-p "decrease?")
>    (set-frame-height nil (1- (frame-text-height)) nil t))
> 
> here?

Any technique to decrease by single pixels will do.  I just find the
mouse to be the most convenient one; but that's me.

I also asked to verify after each decrement that the mode line will
not be overlaid by some other text, so I think a loop is not TRT here.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[martin rudalics]

 >> (while (y-or-n-p "decrease?")
 >>     (set-frame-height nil (1- (frame-text-height)) nil t))
 >>
 >> here?
 >
 > Any technique to decrease by single pixels will do.  I just find the
 > mouse to be the most convenient one; but that's me.
 >
 > I also asked to verify after each decrement that the mode line will
 > not be overlaid by some other text, so I think a loop is not TRT here.

I thought the y-or-n-p would give Bruno time to verify that.

martin

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Mon, 03 Nov 2014 19:01:59 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: oitofelix@gnu.org, 18912@debbugs.gnu.org
> 
> I thought the y-or-n-p would give Bruno time to verify that.

If it does, fine with me.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> I'd like to solve this problem, not paper over it.  I hope you agree
> that solving it is better than working around it.

Sure, given that it's practical to solve.

> I find it hard to believe that we won't find the root cause, so I
> think we don't need to consider that possibility.

I'm glad to hear it!  I'll do whatever I can to help you figure this
out. :-)

> Here are the first instructions to get information that will help us
> start digging into this.  (These are in addition to what Martin
> already requested.)

I've replied to Martin's request already.

> First, please build Emacs without optimizations and with extra
> checking code enabled:
> 
>   CFLAGS='-O0 -g3' ./configure --prefix=/home/felix/opt/emacs-24.4 --with-x-toolkit=athena --enable-checking='yes,glyphs'
> 
> (I only care about CFLAGS and the --enable-checking= option; the rest
> I just copied from your original report, but feel free to change them
> if you want.  The --enable-checking= option is required to compile the
> dump-glyph-matrix command I ask you to use below.)

Here is what Emacs says about the configuration step:

  Configured using:
   `configure --prefix=/home/felix/opt/emacs-24.4-debug
  --with-x-toolkit=athena --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3''

I did a VPATH build, though.

> After 'configure' finishes, invoke "make".  You don't have to invoke
> "make install", as Emacs can be run from the src/ directory where it
> was built.

I did that: ran it right away from the build directory.

> Now start Emacs you've just build with "emacs -Q", type the "C-x d"
> command that you say is sufficient to reproduce the problem, and then
> type this:
> 
>   M-x dump-glyph-matrix RET
> 
> This outputs to the standard error stream the description of the
> internal data structure, called "glyph matrix", which Emacs maintains
> for each window on a GUI frame.  Please post that output (you may wish
> to redirect stderr to a file when you invoke Emacs, to make that
> easier).
> 
> Please do this once for the "good" configuration, and another time for
> the "bad" configuration, but please make sure you invoke Emacs the
> same in both cases and type the same "C-x d" command in each case.

The outputs of the 'dump-glyph-matrix' command for both the good and bad
configurations are in the attached files 'dump-glyph-matrix-good.txt'
and 'dump-glyph-matrix-bad.txt', respectively; they are identical, though.

> Next, in the "bad" configuration and with the listing of /dev and
> corrupted mode line displayed, type this:
> 
>   M-: (setq frame-resize-pixelwise t) RET
> 
> Now carefully decrease the frame's height by dragging its upper or
> lower edge with the mouse.  Please drag it slowly and carefully, so
> that the frame is resized one pixel at a time.  After each resize,
> please see if the mode line is no longer corrupted.  Perhaps kill the
> buffer and type "C-x d" again to make sure the corruption disappeared
> for good.  The first time the mode line stops being corrupted, type
> 
>   M-x dump-glyph-matrix RET
> 
> again, and include this (3rd) output in your message.  Also, please
> tell how many pixels did you subtract from the original frame height
> before the corruption disappeared (assuming it ever does).

For the sake of precision I used the method suggested by Martin:
evaluating the expression

(while (y-or-n-p "decrease?")
  (set-frame-height nil (1- (frame-text-height)) nil t))

in the requested condition.  In order to not be fooled by a spurious
mode-line redrawing, I killed the buffer and invoked 'C-x d /dev RET'
again and the glitch was gone, after one iteration (minus 1 pixel).  The
output of the command 'dump-glyph-matrix' is in the attached file named
'dump-glyph-matrix-bad-resized.txt'.  This one is different from the
other two.

Then, to be sure I executed immediately the inverse procedure by
evaluating the expression

(while (y-or-n-p "increase?")
  (set-frame-height nil (1+ (frame-text-height)) nil t))

and therefore incrementing the frame's height by 1 pixel.  After killing
and getting again to the Dired buffer, the glitch was back.

> Where are the instructions to use the debugger, you ask?  Well, not
> yet, but maybe after we see what the above tells us.

I'm waiting for further instructions. :-P

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;

[-- Attachment #1.2: dump-glyph-matrix-bad.txt --]
[-- Type: text/plain, Size: 3639 bytes --]

PT = 214, BEGV = 1. ZV = 10370
Cursor x = 468, y = 72, hpos = 52, vpos = 4
=============================================
  0: (1) ''
  0: (1) '  /dev:[\n]'
  0: (1) ''
  1: (1) ''
  1: (1) '  total used in directory 4 available 10240[\n]'
  1: (1) ''
  2: (1) ''
  2: (1) '  drwxr-xr-x  19 root root        3500 Nov  1 21:13 .[\n]'
  2: (1) ''
  3: (1) ''
  3: (1) '  drwxr-xr-x  22 root root        4096 Out 27 17:58 ..[\n]'
  3: (1) ''
  4: (1) ''
  4: (1) '  crw-rw----   1 root video    10, 175 Out 30 22:18 agpgart[\n]'
  4: (1) ''
  5: (1) ''
  5: (1) '  crw-rw----+  1 root audio    14,   4 Out 30 22:18 audio[\n]'
  5: (1) ''
  6: (1) ''
  6: (1) '  crw-------   1 root root     10, 235 Out 30 22:18 autofs[\n]'
  6: (1) ''
  7: (1) ''
  7: (1) '  drwxr-xr-x   2 root root         400 Out 30 22:18 block[\n]'
  7: (1) ''
  8: (1) ''
  8: (1) '  drwxr-xr-x   2 root root         100 Out 30 22:16 bsg[\n]'
  8: (1) ''
  9: (1) ''
  9: (1) '  crw-------   1 root root     10, 234 Out 30 22:17 btrfs-control[\n]'
  9: (1) ''
 10: (1) ''
 10: (1) '  drwxr-xr-x   3 root root          60 Out 30 22:16 bus[\n]'
 10: (1) ''
 11: (1) ''
 11: (1) '  drwxr-xr-x   2 root root        3340 Nov  3 15:28 char[\n]'
 11: (1) ''
 12: (1) ''
 12: (1) '  crw-------   1 root root      5,   1 Out 30 22:18 console[\n]'
 12: (1) ''
 13: (1) ''
 13: (1) '  lrwxrwxrwx   1 root root          11 Out 30 22:16 core -> /proc/kcore[\n]'
 13: (1) ''
 14: (1) ''
 14: (1) '  drwxr-xr-x   2 root root          60 Out 30 22:16 cpu[\n]'
 14: (1) ''
 15: (1) ''
 15: (1) '  crw-------   1 root root     10,  62 Out 30 22:18 cpu_dma_latency[\n]'
 15: (1) ''
 16: (1) ''
 16: (1) '  crw-rw-rw-   1 root root     10, 203 Out 30 22:18 cuse[\n]'
 16: (1) ''
 17: (1) ''
 17: (1) '  drwxr-xr-x   5 root root         100 Out 30 22:17 disk[\n]'
 17: (1) ''
 18: (1) ''
 18: (1) '  brw-rw----   1 root disk    254,   0 Out 30 22:18 dm-0[\n]'
 18: (1) ''
 19: (1) ''
 19: (1) '  brw-rw----   1 root disk    254,   1 Out 30 22:18 dm-1[\n]'
 19: (1) ''
 20: (1) ''
 20: (1) '  brw-rw----   1 root disk    254,   2 Out 30 22:18 dm-2[\n]'
 20: (1) ''
 21: (1) ''
 21: (1) '  brw-rw----   1 root disk    254,   3 Out 30 22:18 dm-3[\n]'
 21: (1) ''
 22: (1) ''
 22: (1) '  drwxr-xr-x   2 root root          80 Out 30 22:18 dri[\n]'
 22: (1) ''
 23: (1) ''
 23: (1) '  crw-rw----+  1 root audio    14,   3 Out 30 22:18 dsp[\n]'
 23: (1) ''
 24: (1) ''
 24: (1) '  crw-rw----   1 root video    29,   0 Out 30 22:18 fb0[\n]'
 24: (1) ''
 25: (1) ''
 25: (1) '  lrwxrwxrwx   1 root root          13 Out 30 22:16 fd -> /proc/self/fd[\n]'
 25: (1) ''
 26: (1) ''
 26: (1) '  drwxr-xr-x   2 root root         100 Out 30 22:17 felix-laptop[\n]'
 26: (1) ''
 27: (1) ''
 27: (1) '  crw-rw-rw-   1 root root      1,   7 Out 30 22:18 full[\n]'
 27: (1) ''
 28: (1) ''
 28: (1) '  crw-rw-rw-   1 root root     10, 229 Out 30 22:18 fuse[\n]'
 28: (1) ''
 29: (1) ''
 29: (1) '  crw-------   1 root root    251,   0 Nov  1 21:13 hidraw0[\n]'
 29: (1) ''
 30: (1) ''
 30: (1) '  crw-------   1 root root    251,   1 Nov  1 00:43 hidraw1[\n]'
 30: (1) ''
 31: (1) ''
 31: (1) '  crw-------   1 root root     10, 228 Out 30 22:18 hpet[\n]'
 31: (1) ''
 32: (1) ''
 32: (1) '  drwxr-xr-x   2 root root           0 Out 30 22:17 hugepages[\n]'
 32: (1) ''
 33: (1) ''
 33: (1) '  lrwxrwxrwx   1 root root          25 Out 30 22:17 initctl -> /run/systemd/init'
 33: (1) ''
 34: (0) ''
 34: (0) ''
 34: (0) ''
 35: (0) ''
 35: (0) ''
 35: (0) ''
 36: (0) ''
 36: (0) ''
 36: (0) ''
 37: (1) ''
 37: (1) ' U:%%-  dev                 Top L5     (Dired by name)                              '
 37: (1) ''

[-- Attachment #1.3: dump-glyph-matrix-bad-resized.txt --]
[-- Type: text/plain, Size: 3687 bytes --]

PT = 214, BEGV = 1. ZV = 10370
Cursor x = 468, y = 72, hpos = 52, vpos = 4
=============================================
  0: (1) ''
  0: (1) '  /dev:[\n]'
  0: (1) ''
  1: (1) ''
  1: (1) '  total used in directory 4 available 10240[\n]'
  1: (1) ''
  2: (1) ''
  2: (1) '  drwxr-xr-x  19 root root        3500 Nov  1 21:13 .[\n]'
  2: (1) ''
  3: (1) ''
  3: (1) '  drwxr-xr-x  22 root root        4096 Out 27 17:58 ..[\n]'
  3: (1) ''
  4: (1) ''
  4: (1) '  crw-rw----   1 root video    10, 175 Out 30 22:18 agpgart[\n]'
  4: (1) ''
  5: (1) ''
  5: (1) '  crw-rw----+  1 root audio    14,   4 Out 30 22:18 audio[\n]'
  5: (1) ''
  6: (1) ''
  6: (1) '  crw-------   1 root root     10, 235 Out 30 22:18 autofs[\n]'
  6: (1) ''
  7: (1) ''
  7: (1) '  drwxr-xr-x   2 root root         400 Out 30 22:18 block[\n]'
  7: (1) ''
  8: (1) ''
  8: (1) '  drwxr-xr-x   2 root root         100 Out 30 22:16 bsg[\n]'
  8: (1) ''
  9: (1) ''
  9: (1) '  crw-------   1 root root     10, 234 Out 30 22:17 btrfs-control[\n]'
  9: (1) ''
 10: (1) ''
 10: (1) '  drwxr-xr-x   3 root root          60 Out 30 22:16 bus[\n]'
 10: (1) ''
 11: (1) ''
 11: (1) '  drwxr-xr-x   2 root root        3340 Nov  3 15:28 char[\n]'
 11: (1) ''
 12: (1) ''
 12: (1) '  crw-------   1 root root      5,   1 Out 30 22:18 console[\n]'
 12: (1) ''
 13: (1) ''
 13: (1) '  lrwxrwxrwx   1 root root          11 Out 30 22:16 core -> /proc/kcore[\n]'
 13: (1) ''
 14: (1) ''
 14: (1) '  drwxr-xr-x   2 root root          60 Out 30 22:16 cpu[\n]'
 14: (1) ''
 15: (1) ''
 15: (1) '  crw-------   1 root root     10,  62 Out 30 22:18 cpu_dma_latency[\n]'
 15: (1) ''
 16: (1) ''
 16: (1) '  crw-rw-rw-   1 root root     10, 203 Out 30 22:18 cuse[\n]'
 16: (1) ''
 17: (1) ''
 17: (1) '  drwxr-xr-x   5 root root         100 Out 30 22:17 disk[\n]'
 17: (1) ''
 18: (1) ''
 18: (1) '  brw-rw----   1 root disk    254,   0 Out 30 22:18 dm-0[\n]'
 18: (1) ''
 19: (1) ''
 19: (1) '  brw-rw----   1 root disk    254,   1 Out 30 22:18 dm-1[\n]'
 19: (1) ''
 20: (1) ''
 20: (1) '  brw-rw----   1 root disk    254,   2 Out 30 22:18 dm-2[\n]'
 20: (1) ''
 21: (1) ''
 21: (1) '  brw-rw----   1 root disk    254,   3 Out 30 22:18 dm-3[\n]'
 21: (1) ''
 22: (1) ''
 22: (1) '  drwxr-xr-x   2 root root          80 Out 30 22:18 dri[\n]'
 22: (1) ''
 23: (1) ''
 23: (1) '  crw-rw----+  1 root audio    14,   3 Out 30 22:18 dsp[\n]'
 23: (1) ''
 24: (1) ''
 24: (1) '  crw-rw----   1 root video    29,   0 Out 30 22:18 fb0[\n]'
 24: (1) ''
 25: (1) ''
 25: (1) '  lrwxrwxrwx   1 root root          13 Out 30 22:16 fd -> /proc/self/fd[\n]'
 25: (1) ''
 26: (1) ''
 26: (1) '  drwxr-xr-x   2 root root         100 Out 30 22:17 felix-laptop[\n]'
 26: (1) ''
 27: (1) ''
 27: (1) '  crw-rw-rw-   1 root root      1,   7 Out 30 22:18 full[\n]'
 27: (1) ''
 28: (1) ''
 28: (1) '  crw-rw-rw-   1 root root     10, 229 Out 30 22:18 fuse[\n]'
 28: (1) ''
 29: (1) ''
 29: (1) '  crw-------   1 root root    251,   0 Nov  1 21:13 hidraw0[\n]'
 29: (1) ''
 30: (1) ''
 30: (1) '  crw-------   1 root root    251,   1 Nov  1 00:43 hidraw1[\n]'
 30: (1) ''
 31: (1) ''
 31: (1) '  crw-------   1 root root     10, 228 Out 30 22:18 hpet[\n]'
 31: (1) ''
 32: (1) ''
 32: (1) '  drwxr-xr-x   2 root root           0 Out 30 22:17 hugepages[\n]'
 32: (1) ''
 33: (0) ''
 33: (0) '  lrwxrwxrwx   1 root root          25 Out 30 22:17 initctl -> /run/systemd/init'
 33: (0) ''
 34: (0) ''
 34: (0) ''
 34: (0) ''
 35: (0) ''
 35: (0) ' U:%%-  dev                 Top L5     (Dired by name)                              '
 35: (0) ''
 36: (1) ''
 36: (1) ' U:%%-  dev                 Top L5     (Dired by name)                              '
 36: (1) ''

[-- Attachment #1.4: dump-glyph-matrix-good.txt --]
[-- Type: text/plain, Size: 3639 bytes --]

PT = 214, BEGV = 1. ZV = 10370
Cursor x = 468, y = 72, hpos = 52, vpos = 4
=============================================
  0: (1) ''
  0: (1) '  /dev:[\n]'
  0: (1) ''
  1: (1) ''
  1: (1) '  total used in directory 4 available 10240[\n]'
  1: (1) ''
  2: (1) ''
  2: (1) '  drwxr-xr-x  19 root root        3500 Nov  1 21:13 .[\n]'
  2: (1) ''
  3: (1) ''
  3: (1) '  drwxr-xr-x  22 root root        4096 Out 27 17:58 ..[\n]'
  3: (1) ''
  4: (1) ''
  4: (1) '  crw-rw----   1 root video    10, 175 Out 30 22:18 agpgart[\n]'
  4: (1) ''
  5: (1) ''
  5: (1) '  crw-rw----+  1 root audio    14,   4 Out 30 22:18 audio[\n]'
  5: (1) ''
  6: (1) ''
  6: (1) '  crw-------   1 root root     10, 235 Out 30 22:18 autofs[\n]'
  6: (1) ''
  7: (1) ''
  7: (1) '  drwxr-xr-x   2 root root         400 Out 30 22:18 block[\n]'
  7: (1) ''
  8: (1) ''
  8: (1) '  drwxr-xr-x   2 root root         100 Out 30 22:16 bsg[\n]'
  8: (1) ''
  9: (1) ''
  9: (1) '  crw-------   1 root root     10, 234 Out 30 22:17 btrfs-control[\n]'
  9: (1) ''
 10: (1) ''
 10: (1) '  drwxr-xr-x   3 root root          60 Out 30 22:16 bus[\n]'
 10: (1) ''
 11: (1) ''
 11: (1) '  drwxr-xr-x   2 root root        3340 Nov  3 15:28 char[\n]'
 11: (1) ''
 12: (1) ''
 12: (1) '  crw-------   1 root root      5,   1 Out 30 22:18 console[\n]'
 12: (1) ''
 13: (1) ''
 13: (1) '  lrwxrwxrwx   1 root root          11 Out 30 22:16 core -> /proc/kcore[\n]'
 13: (1) ''
 14: (1) ''
 14: (1) '  drwxr-xr-x   2 root root          60 Out 30 22:16 cpu[\n]'
 14: (1) ''
 15: (1) ''
 15: (1) '  crw-------   1 root root     10,  62 Out 30 22:18 cpu_dma_latency[\n]'
 15: (1) ''
 16: (1) ''
 16: (1) '  crw-rw-rw-   1 root root     10, 203 Out 30 22:18 cuse[\n]'
 16: (1) ''
 17: (1) ''
 17: (1) '  drwxr-xr-x   5 root root         100 Out 30 22:17 disk[\n]'
 17: (1) ''
 18: (1) ''
 18: (1) '  brw-rw----   1 root disk    254,   0 Out 30 22:18 dm-0[\n]'
 18: (1) ''
 19: (1) ''
 19: (1) '  brw-rw----   1 root disk    254,   1 Out 30 22:18 dm-1[\n]'
 19: (1) ''
 20: (1) ''
 20: (1) '  brw-rw----   1 root disk    254,   2 Out 30 22:18 dm-2[\n]'
 20: (1) ''
 21: (1) ''
 21: (1) '  brw-rw----   1 root disk    254,   3 Out 30 22:18 dm-3[\n]'
 21: (1) ''
 22: (1) ''
 22: (1) '  drwxr-xr-x   2 root root          80 Out 30 22:18 dri[\n]'
 22: (1) ''
 23: (1) ''
 23: (1) '  crw-rw----+  1 root audio    14,   3 Out 30 22:18 dsp[\n]'
 23: (1) ''
 24: (1) ''
 24: (1) '  crw-rw----   1 root video    29,   0 Out 30 22:18 fb0[\n]'
 24: (1) ''
 25: (1) ''
 25: (1) '  lrwxrwxrwx   1 root root          13 Out 30 22:16 fd -> /proc/self/fd[\n]'
 25: (1) ''
 26: (1) ''
 26: (1) '  drwxr-xr-x   2 root root         100 Out 30 22:17 felix-laptop[\n]'
 26: (1) ''
 27: (1) ''
 27: (1) '  crw-rw-rw-   1 root root      1,   7 Out 30 22:18 full[\n]'
 27: (1) ''
 28: (1) ''
 28: (1) '  crw-rw-rw-   1 root root     10, 229 Out 30 22:18 fuse[\n]'
 28: (1) ''
 29: (1) ''
 29: (1) '  crw-------   1 root root    251,   0 Nov  1 21:13 hidraw0[\n]'
 29: (1) ''
 30: (1) ''
 30: (1) '  crw-------   1 root root    251,   1 Nov  1 00:43 hidraw1[\n]'
 30: (1) ''
 31: (1) ''
 31: (1) '  crw-------   1 root root     10, 228 Out 30 22:18 hpet[\n]'
 31: (1) ''
 32: (1) ''
 32: (1) '  drwxr-xr-x   2 root root           0 Out 30 22:17 hugepages[\n]'
 32: (1) ''
 33: (1) ''
 33: (1) '  lrwxrwxrwx   1 root root          25 Out 30 22:17 initctl -> /run/systemd/init'
 33: (1) ''
 34: (0) ''
 34: (0) ''
 34: (0) ''
 35: (0) ''
 35: (0) ''
 35: (0) ''
 36: (0) ''
 36: (0) ''
 36: (0) ''
 37: (1) ''
 37: (1) ' U:%%-  dev                 Top L5     (Dired by name)                              '
 37: (1) ''

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Mon, 03 Nov 2014 18:06:28 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: rudalics@gmx.at, 18912@debbugs.gnu.org
> 
> The outputs of the 'dump-glyph-matrix' command for both the good and bad
> configurations are in the attached files 'dump-glyph-matrix-good.txt'
> and 'dump-glyph-matrix-bad.txt', respectively; they are identical, though.

So you are saying that this last line:

   33: (1) '  lrwxrwxrwx   1 root root          25 Out 30 22:17 initctl -> /run/systemd/init'

which appears in both the "good" and the "bad" dumps, is nevertheless
displayed (overwrites the mode line) only in the "bad" configuration,
and is not visible at all in the "good" one, is that right?

> For the sake of precision I used the method suggested by Martin:
> evaluating the expression
> 
> (while (y-or-n-p "decrease?")
>   (set-frame-height nil (1- (frame-text-height)) nil t))
> 
> in the requested condition.  In order to not be fooled by a spurious
> mode-line redrawing, I killed the buffer and invoked 'C-x d /dev RET'
> again and the glitch was gone, after one iteration (minus 1 pixel).

So hereby you have your workaround already, for free: just make the
frame one pixel lower.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Mon, 03 Nov 2014 22:24:57 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18912@debbugs.gnu.org
> 
> > Date: Mon, 03 Nov 2014 18:06:28 -0200
> > From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> > CC: rudalics@gmx.at, 18912@debbugs.gnu.org
> > 
> > For the sake of precision I used the method suggested by Martin:
> > evaluating the expression
> > 
> > (while (y-or-n-p "decrease?")
> >   (set-frame-height nil (1- (frame-text-height)) nil t))
> > 
> > in the requested condition.  In order to not be fooled by a spurious
> > mode-line redrawing, I killed the buffer and invoked 'C-x d /dev RET'
> > again and the glitch was gone, after one iteration (minus 1 pixel).

What happens in the "good" configuration if you decrease or increase
the frame height there by 1 pixel?

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Mon, 03 Nov 2014 22:29:57 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18912@debbugs.gnu.org
> 
> What happens in the "good" configuration if you decrease or increase
> the frame height there by 1 pixel?

Also, what does the following display in both "good" and "bad"
configurations in the first frame displayed by "emacs -Q" that has the
original, unaltered by 1-pixel changes, size?

  M-: (pos-visible-in-window-p t nil t) RET

Please invoke this after "C-x d" in each case.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> Also, what does the following display in both "good" and "bad"
> configurations in the first frame displayed by "emacs -Q" that has the
> original, unaltered by 1-pixel changes, size?
> 
>   M-: (pos-visible-in-window-p t nil t) RET
> 
> Please invoke this after "C-x d" in each case.

In the *good* configuration: (0 594 0 17 1 33)
In the *bad* configuration: (0 594 0 17 1 33)

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Mon, 03 Nov 2014 19:01:43 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> >   M-: (pos-visible-in-window-p t nil t) RET
> > 
> > Please invoke this after "C-x d" in each case.
> 
> In the *good* configuration: (0 594 0 17 1 33)
> In the *bad* configuration: (0 594 0 17 1 33)

Again identical.  Looks like indeed it's some problem with your
graphics card, because Emacs gets the same information in both cases:
in both cases, only 1 pixel of the last line is visible.

I'll try to think about additional tests, but meanwhile I suggest that
you try lowering the level of the acceleration of your card, and see
if that helps.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> Again identical.  Looks like indeed it's some problem with your
> graphics card, because Emacs gets the same information in both cases:
> in both cases, only 1 pixel of the last line is visible.
> 
> I'll try to think about additional tests, but meanwhile I suggest that
> you try lowering the level of the acceleration of your card, and see
> if that helps.

Totally disabling acceleration by using the driver's option "NoAccel",
seems to fix the problem.

The conclusion we reach is that it's not an Emacs bug, despite the fact
that this weirdness only manifests in Emacs.  I never have had any
problem with my graphics card in the 5 years of usage of this machine,
working with any kind of application you can imagine, being the "Emacs
bug" the only exception.

So we came to the point where we actually find that it's not possible to
solve the bug, because it's beyond the realm of Emacs.  That doesn't
mean, however, that Emacs can't help to work around it!  As Emacs is the
only piece of software, that I know of, that triggers the bug, it's in
principle equivalent to fix the problem in its root, or to make Emacs to
work around it.  Solving the actual bug seems at first glance much
harder, as no one knows what's actually causing this mysterious bug,
that only manifests in Emacs.  On the other hand, we have a clear
understanding of what feature Emacs has to provide to *virtually* fix
the bug.

So I kindly ask you: please, provide a way to make Emacs optionally
redraw the mode-line after any scroll operation. ;-)

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Bruno Félix Rezende Ribeiro wrote:
> The conclusion we reach is that it's not an Emacs bug, despite the fact
> that this weirdness only manifests in Emacs.

Just occurred to me that it might be possible for that to be a bug
within Emacs which is only triggered when acceleration is enabled.  WDYT?

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Tue, 04 Nov 2014 06:25:09 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> Bruno Félix Rezende Ribeiro wrote:
> > The conclusion we reach is that it's not an Emacs bug, despite the fact
> > that this weirdness only manifests in Emacs.
> 
> Just occurred to me that it might be possible for that to be a bug
> within Emacs which is only triggered when acceleration is enabled.  WDYT?

You'd need to explain how Emacs succeeds in that, when it uses Xlib
and higher-level APIs, which AFAIK are unaware of any accelerations.
Emacs itself is certainly unaware of that, and does the same things
regardless.

Moreover, the fact that running xrefresh, which is not an Emacs
command, fixes the display is yet another argument against this
hypothesis.  xrefresh doesn't communicate with Emacs, so the only way
it could fix the display is if the data supplied by Emacs was correct.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[martin rudalics]

 > Moreover, the fact that running xrefresh, which is not an Emacs
 > command, fixes the display is yet another argument against this
 > hypothesis.  xrefresh doesn't communicate with Emacs, so the only way
 > it could fix the display is if the data supplied by Emacs was correct.

But the data supplied by us is still the same?

martin

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Tue, 04 Nov 2014 20:24:27 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 18912@debbugs.gnu.org
> 
>  > Moreover, the fact that running xrefresh, which is not an Emacs
>  > command, fixes the display is yet another argument against this
>  > hypothesis.  xrefresh doesn't communicate with Emacs, so the only way
>  > it could fix the display is if the data supplied by Emacs was correct.
> 
> But the data supplied by us is still the same?

Of course.  There's no communications between Emacs and X when
xrefresh runs, AFAIK.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Stefan Monnier]

> Moreover, the fact that running xrefresh, which is not an Emacs
> command, fixes the display is yet another argument against this
> hypothesis.  xrefresh doesn't communicate with Emacs, so the only way
> it could fix the display is if the data supplied by Emacs was correct.

Actually xrefresh does (indirectly) communicate with Emacs, IIRC, since
it causes the X server to generate "expose" events to redraw everything.


        Stefan

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>,
>   18912@debbugs.gnu.org
> Date: Tue, 04 Nov 2014 15:13:51 -0500
> 
> > Moreover, the fact that running xrefresh, which is not an Emacs
> > command, fixes the display is yet another argument against this
> > hypothesis.  xrefresh doesn't communicate with Emacs, so the only way
> > it could fix the display is if the data supplied by Emacs was correct.
> 
> Actually xrefresh does (indirectly) communicate with Emacs, IIRC, since
> it causes the X server to generate "expose" events to redraw everything.

Then it should have the same effect as redraw-display, but evidently
doesn't.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Moreover, the fact that running xrefresh, which is not an Emacs
>> command, fixes the display is yet another argument against this
>> hypothesis.  xrefresh doesn't communicate with Emacs, so the only way
>> it could fix the display is if the data supplied by Emacs was correct.
>
> Actually xrefresh does (indirectly) communicate with Emacs, IIRC, since
> it causes the X server to generate "expose" events to redraw everything.

That doesn't mean that the X server (or the compositor) has to ask the
application to redraw the window contents, it may be reusing an
off-screen copy of it.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> You'd need to explain how Emacs succeeds in that, when it uses Xlib
> and higher-level APIs, which AFAIK are unaware of any accelerations.
> Emacs itself is certainly unaware of that, and does the same things
> regardless.

The Emacs algorithms for redrawing the frame's content could be based on
assumptions about the workings of graphical displays that fail to be
true in some corner cases.

> Moreover, the fact that running xrefresh, which is not an Emacs
> command, fixes the display is yet another argument against this
> hypothesis.  xrefresh doesn't communicate with Emacs, so the only way
> it could fix the display is if the data supplied by Emacs was correct.

Of course 'xrefresh' command doesn't communicate directly with Emacs.
It works by mapping a window, with no background, on top of the Emacs'
frames, and then unmapping it, causing the X server to send a refresh
event to Emacs, that handles it and repaints its frames.  So Emacs *do
know* how to get its frames right, when it wants to.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Tue, 04 Nov 2014 19:09:07 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > You'd need to explain how Emacs succeeds in that, when it uses Xlib
> > and higher-level APIs, which AFAIK are unaware of any accelerations.
> > Emacs itself is certainly unaware of that, and does the same things
> > regardless.
> 
> The Emacs algorithms for redrawing the frame's content could be based on
> assumptions about the workings of graphical displays that fail to be
> true in some corner cases.

AFAIK, the only assumptions made by Emacs are that each screen line of
the display is independently addressable, which means the order of
drawing those lines doesn't matter; and that clipping of partially
visible text works.

> [xrefresh] works by mapping a window, with no background, on top of
> the Emacs' frames, and then unmapping it, causing the X server to
> send a refresh event to Emacs, that handles it and repaints its
> frames.

If we want to make sure Emacs indeed redraws its frame in your case
(rather than X reusing its own copy of the screen, as Andreas points
out), please put a breakpoint in expose_frame, and see if it breaks
when you invoke xrefresh.

> So Emacs *do know* how to get its frames right, when it wants to.

Does it?  We were talking all along about the simplest situation, when
the Emacs frame has only one window and thus a single mode line, and
the clipped text line is the last line of that window.  But this is by
no means so in general.  Here, try this:

  emacs -Q
  C-x d /dev RET
  C-x 2
  C-x o
  C-v

At this point, you should see the lower of the 2 windows selected,
with its contents scrolled, such that each of the 2 windows showing 2
different places in /dev's directory listing.

Now invoke xrefresh to clean up the mode lines and start with a "clean
slate".

Finally, type inside Emacs:

  M-: (set-window-vscroll nil 5 t) RET

How many mode lines did that corrupt?  If both mode lines become
corrupted, does xrefresh succeed in fixing that?

Bonus points for repeating the above after setting mode-line-format to
nil.  I expect you to see that the 2 windows corrupt each other in
that case.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:>> Date: Tue, 04 Nov 2014 19:09:07 -0200

> If we want to make sure Emacs indeed redraws its frame in your case 
> (rather than X reusing its own copy of the screen, as Andreas points 
> out), please put a breakpoint in expose_frame, and see if it breaks 
> when you invoke xrefresh.

Yes, it does.

> Does it?  We were talking all along about the simplest situation,
> when the Emacs frame has only one window and thus a single mode line,
> and the clipped text line is the last line of that window.  But this
> is by no means so in general.  Here, try this:
> 
> emacs -Q C-x d /dev RET C-x 2 C-x o C-v
> 
> At this point, you should see the lower of the 2 windows selected, 
> with its contents scrolled, such that each of the 2 windows showing
> 2 different places in /dev's directory listing.
> 
> Now invoke xrefresh to clean up the mode lines and start with a
> "clean slate".

I don't need to.  The 'C-x o' command repaints the corrupted mode-line
and the one of the lower window doesn't get corrupt with scrolling,
even with other frame sizes --- including full-screen.  Scrolling the
upper window will corrupt its mode-line again, though.

> Finally, type inside Emacs:
> 
> M-: (set-window-vscroll nil 5 t) RET
> 
> How many mode lines did that corrupt?

Immediately after the command, completely the lower one, and only
slightly the upper one.

> If both mode lines become corrupted, does xrefresh succeed in fixing 
> that?

It *does* succeed in fixing the lower mode-line (the current one).
The upper one continues slightly corrupted until it becomes the
current one (eg. by 'C-x o'), in which case it becomes fine until next
scrolling.

> Bonus points for repeating the above after setting mode-line-format
> to nil.  I expect you to see that the 2 windows corrupt each other
> in that case.

Indeed.  The upper one is corrupting the first line of the lower one.
However, scrolling the lower one redraws that line and it doesn't get
corrupted again until scrolling the upper window.


-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Wed, 05 Nov 2014 19:38:52 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> > Finally, type inside Emacs:
> > 
> > M-: (set-window-vscroll nil 5 t) RET
> > 
> > How many mode lines did that corrupt?
> 
> Immediately after the command, completely the lower one, and only
> slightly the upper one.

The "slightly" part depends on the value of vscroll, which was 5 in
this experiment.  You can play with the 2nd argument of
set-window-vscroll to see the effect.

> > If both mode lines become corrupted, does xrefresh succeed in fixing 
> > that?
> 
> It *does* succeed in fixing the lower mode-line (the current one).
> The upper one continues slightly corrupted until it becomes the
> current one (eg. by 'C-x o'), in which case it becomes fine until next
> scrolling.

Which means, as I hope you understand, that to do what you want, Emacs
needs to have a very clever global strategy for refreshing the mode
lines, which considers all the windows that were updated, instead of
treating each window separately, which is what it does now.

> > Bonus points for repeating the above after setting mode-line-format
> > to nil.  I expect you to see that the 2 windows corrupt each other
> > in that case.
> 
> Indeed.  The upper one is corrupting the first line of the lower one.
> However, scrolling the lower one redraws that line and it doesn't get
> corrupted again until scrolling the upper window.

In this case, there are no mode lines to refresh, so this directly
affects the order in which redisplay redraws lines in each window.

I think we have spent enough time on this, and we understand well
enough that this problem cannot be possibly solved by Emacs in any
reasonably simple way.  So I'm closing this bug, as this is not an
Emacs problem.  My suggestion to you is to upgrade your video firmware
and device driver, or disable acceleration.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Stefan Monnier]

> Emacs problem.  My suggestion to you is to upgrade your video firmware
> and device driver, or disable acceleration.

Don't forget the "report the bug" part (unless it's already fixed in
the latest version, of course).


        Stefan

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Stefan Monnier]

> Totally disabling acceleration by using the driver's option "NoAccel",
> seems to fix the problem.

[ Told ya!  ;-)  ]

> The conclusion we reach is that it's not an Emacs bug, despite the fact
> that this weirdness only manifests in Emacs.  I never have had any
> problem with my graphics card in the 5 years of usage of this machine,
> working with any kind of application you can imagine, being the "Emacs
> bug" the only exception.

Of course, your graphics driver has probably changed over the course of
those 5 years, so maybe the driver bug simply wasn't present earlier.

Could you please open a bug-report to the maintainers of your graphics
driver and try to make sure it's fixed there?

> Just occurred to me that it might be possible for that to be a bug
> within Emacs which is only triggered when acceleration is enabled.  WDYT?

Of course it's possible.
But it seems unlikely, since AFAIK the acceleration code only affects
what/how the pixels are written but not how the X server talks to
the application.


        Stefan

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Stefan Monnier wrote:
> [ Told ya!  ;-)  ]

Yeah, but I don't remember getting this far investigating the problem
last time.  You do have impressive recollection capabilities, though.

> Of course, your graphics driver has probably changed over the course of
> those 5 years, so maybe the driver bug simply wasn't present earlier.

This bug torments me since the beginning of my usage of dual-headed setups.

> Could you please open a bug-report to the maintainers of your graphics
> driver and try to make sure it's fixed there?

I could do it, for sure!  However I have the feeling that in the end
they will blame Emacs, as nothing similar happens to any other
application, AFAIK.

> Of course it's possible.
> But it seems unlikely, since AFAIK the acceleration code only affects
> what/how the pixels are written but not how the X server talks to
> the application.

Maybe that glitch is only a side effect of Emacs presuming something it
shouldn't presume.  This is only speculation, but think about it.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Stefan Monnier]

>> Could you please open a bug-report to the maintainers of your graphics
>> driver and try to make sure it's fixed there?
> I could do it, for sure!  However I have the feeling that in the end
> they will blame Emacs, as nothing similar happens to any other
> application, AFAIK.

I think the fact that the bug disappears when you set NoAccel is a strong
sign that the problem might be on their side.  So until you've reported
the bug there and they throw the ball back at us, there's not
much motivation for us to work on it.

> Maybe that glitch is only a side effect of Emacs presuming something it
> shouldn't presume.  This is only speculation, but think about it.

As I said, it's possible.  But unlikely, at this point.


        Stefan

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Tue, 04 Nov 2014 04:05:17 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > Again identical.  Looks like indeed it's some problem with your
> > graphics card, because Emacs gets the same information in both cases:
> > in both cases, only 1 pixel of the last line is visible.
> > 
> > I'll try to think about additional tests, but meanwhile I suggest that
> > you try lowering the level of the acceleration of your card, and see
> > if that helps.
> 
> Totally disabling acceleration by using the driver's option "NoAccel",
> seems to fix the problem.

Good.  This seems to close the issue: the root cause is indeed some
problem with your card/driver.  It's not an Emacs bug.

> The conclusion we reach is that it's not an Emacs bug, despite the fact
> that this weirdness only manifests in Emacs.

Emacs uses standard Xlib calls to draw its windows and communicate to
X the dimensions to be used to clip partially visible lines.  Any
program that does the same will bump into the same issues.

> So we came to the point where we actually find that it's not possible to
> solve the bug, because it's beyond the realm of Emacs.

It's not possible to solve it in Emacs, but not in general.  Your card
probably has firmware, which could be updated, and a device driver,
which could be upgraded.  I'd suggest to do that, if at all possible
and practical.  Or even replace the card with another one.

> So I kindly ask you: please, provide a way to make Emacs optionally
> redraw the mode-line after any scroll operation. ;-)

I'm not yet convinced that Emacs can do _anything_ to provide a
workaround for this problem.  See my other messages as to why.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[martin rudalics]

 > Emacs uses standard Xlib calls to draw its windows and communicate to
 > X the dimensions to be used to clip partially visible lines.  Any
 > program that does the same will bump into the same issues.

Today hardly any program restricts window sizes in the way Emacs does
via size hints.

 > It's not possible to solve it in Emacs, but not in general.

There must be one "not" too many here ;-)

 > Your card
 > probably has firmware, which could be updated, and a device driver,
 > which could be upgraded.  I'd suggest to do that, if at all possible
 > and practical.  Or even replace the card with another one.
 >
 >> So I kindly ask you: please, provide a way to make Emacs optionally
 >> redraw the mode-line after any scroll operation. ;-)
 >
 > I'm not yet convinced that Emacs can do _anything_ to provide a
 > workaround for this problem.  See my other messages as to why.

We should make sure that the bug happens with every pixelwise resize
operation, for example, when dragging the mode line between windows.  If
it doesn't happen in such cases, the problem might be due in some sort
of interference of the window manager which simply doesn't like Emacs to
make a frame fullscreen when at the same time fullscreen doesn't match
Emacs' size hints.

martin

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

martin rudalics wrote:
> We should make sure that the bug happens with every pixelwise resize 
> operation, for example, when dragging the mode line between windows.

After evaluating

(setq window-resize-pixelwise t)

dragging the mode-line between windows triggers the bug.  I can see
the mode-line getting corrupt again and again, for brief moments[0],
while I move the mode-line over the window's lines, but after I
release the mouse button the mode-line gets redrawn and the glitch
isn't visible until I scroll the window somehow.


Footnotes:

[0] Only for brief moments because the mode-line is repainted after
each pixel boundary is crossed, in effect, fixing the mode-line.  This
is one evidence that Emacs *can do* something about this bug.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:>> Date: Tue, 04 Nov 2014 04:05:17 -0200
> Good.  This seems to close the issue: the root cause is indeed some 
> problem with your card/driver.  It's not an Emacs bug.

It's *probably* not an Emacs bug.  But it's very weird to me the fact
that Emacs redraws its frames correctly when asked by the 'xrefresh'
command, but not when done so by its own 'redraw-display' command.

> Emacs uses standard Xlib calls to draw its windows and communicate
> to X the dimensions to be used to clip partially visible lines.  Any 
> program that does the same will bump into the same issues.

Right.  I haven't noticed glitches in other applications, though.

> It's not possible to solve it in Emacs, but not in general.

Actually I think it's possible to almost solve it in Emacs.  I just
need a way to tell Emacs to force the redraw of the mode-line after
any scrolling is done, and ensure that the mode-line gets redrawn
after the buffer's content, not before it.

> Your card probably has firmware, which could be updated, and a device
> driver, which could be upgraded.  I'd suggest to do that, if at all
> possible and practical.

I would do that, granted the firmware and drivers are free software.

> Or even replace the card with another one.

I can't replace the graphics card, it's a laptop.  Furthermore, I
don't need to, the card is very good for my practical needs, except
for that mode-line thing in Emacs.

> I'm not yet convinced that Emacs can do _anything_ to provide a 
> workaround for this problem.  See my other messages as to why.

Why do you think my proposed workaround wouldn't work?  My answers to
your other messages, and your commentaries, seem to suggest Emacs can
help to work around this.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Tue, 04 Nov 2014 18:14:47 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> > I'm not yet convinced that Emacs can do _anything_ to provide a 
> > workaround for this problem.  See my other messages as to why.
> 
> Why do you think my proposed workaround wouldn't work?  My answers to
> your other messages, and your commentaries, seem to suggest Emacs can
> help to work around this.

Then try this:

  (add-hook 'pre-command-hook 'force-mode-line-update)

(I'm not holding my breath.)

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> Then try this:
> 
>   (add-hook 'pre-command-hook 'force-mode-line-update)

It doesn't work. :-(

In fact, even

  (add-hook 'pre-command-hook (lambda () (call-process "xrefresh")))

doesn't work completely.

The difference between the two, however, is the fact that while
'force-mode-line-update' has no effect at all, so as one scrolls trough
a buffer the mode-line becomes increasingly corrupt, accumulating over
it the trail of all the lines which were once "below" it --- as if the
mode-line's background was never cleared, the 'xrefresh' command makes
Emacs repaint the mode-line's background so at each scrolling the
mode-line is "cleanly" corrupted by the current buffer's line "below"
it, and only by that one.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Wed, 05 Nov 2014 04:28:53 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > Then try this:
> > 
> >   (add-hook 'pre-command-hook 'force-mode-line-update)
> 
> It doesn't work. :-(

Told you so.

> In fact, even
> 
>   (add-hook 'pre-command-hook (lambda () (call-process "xrefresh")))
> 
> doesn't work completely.

I hope you are beginning to understand how non-trivial it is to
implement your workaround, even if we wanted to.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:

> I hope you are beginning to understand how non-trivial it is to
> implement your workaround, even if we wanted to.

Damn!  I was hoping you were beginning to understand how trivial it is
to implement my workaround, even if you didn't want to. ;-)

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> What happens in the "good" configuration if you decrease or increase
> the frame height there by 1 pixel?

It works as expected in both cases.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> So you are saying that this last line:
> 
>    33: (1) '  lrwxrwxrwx   1 root root          25 Out 30 22:17 initctl -> /run/systemd/init'
> 
> which appears in both the "good" and the "bad" dumps, is nevertheless
> displayed (overwrites the mode line) only in the "bad" configuration,
> and is not visible at all in the "good" one, is that right?

Yeah, that's right.

> So hereby you have your workaround already, for free: just make the
> frame one pixel lower.

That's not quite *my* workaround.  Furthermore, I don't need one because
it's hard to believe that we won't find the root cause of this bug,
right? ;-)

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Emacs never writes buffer contents where the mode line should be, so

Unless it needs to write a partial line just above the mode line.

> this problem could only happen if Emacs for some reason becomes
> confused about the window dimensions.

Or the clipping rectangle is wrong for any reason.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>,
>   18912@debbugs.gnu.org
> Date: Mon, 03 Nov 2014 10:08:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Emacs never writes buffer contents where the mode line should be, so
> 
> Unless it needs to write a partial line just above the mode line.
> 
> > this problem could only happen if Emacs for some reason becomes
> > confused about the window dimensions.
> 
> Or the clipping rectangle is wrong for any reason.

It could be that, yes.  Although I generally need to enlarge the frame
by at least 3 pixels before Emacs enables another glyph row for such
clipped display.

Anyway, I hope dump-glyph-matrix will show if this is the case.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[martin rudalics]

 >>    (window-height) ==> 34
 >>    (window-pixel-height) ==> 613
 >
 > Thanks.
 >
 > I don't see anything strange here, the 1-pixel difference shouldn't
 > have caused what you see.
 >
 > Martin, any suggestions how to dig into this further?
 >
 >> Interesting enough, '(window-pixel-height)' returns different values for
 >> both configurations under the "same" circumstances.  Furthermore, in
 >> both configurations '(window-height)' returns one line more than what
 >> was actually shown.  Therefore, both expressions seem to suggest an "off
 >> by one" bug.
 >
 > I see no bug here: both functions return the height of the window
 > including the mode line, so the value sounds correct if you have 33
 > lines of text in that window.

Bruno: Could you please post the results of evaluating

(window--dump-frame)

here.  The results are in a buffer called *window-frame-dump*.  Please
do it for the good and the corrupted frame.

Thanks, martin

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

martin rudalics wrote:
> Bruno: Could you please post the results of evaluating
> 
> (window--dump-frame)
> 
> here.  The results are in a buffer called *window-frame-dump*.  Please
> do it for the good and the corrupted frame.

Here is the result for the *corrupted* frame:

  frame pixel: 756 x 669   cols/lines: 84 x 37   units: 9 x 18
  frame text pixel: 720 x 667   cols/lines: 80 x 37
  tool: 36  scroll: 16  fringe: 18  border: 1  right: 0  bottom: 0

  #<window 3 on dev>   parent: nil
  pixel left: 0   top: 36   size: 754 x 613   new: 0
  char left: 0   top: 2   size: 83 x 34   new: 0
  normal: 1.0 x 1.0   new: 0
  body pixel: 720 x 595   char: 80 x 33
  width left fringe: 9  left margin: 0  right margin: 0
  width right fringe: 9  scroll-bar: 16  divider: 0
  height header-line: 0  mode-line: 18  divider: 0

  #<window 4 on  *Minibuf-0*>   parent: nil
  pixel left: 0   top: 649   size: 754 x 18   new: 0
  char left: 0   top: 36   size: 754 x 1   new: 0
  normal: 1.0 x 1.0   new: 0
  body pixel: 720 x 18   char: 80 x 1
  width left fringe: 9  left margin: 0  right margin: 0
  width right fringe: 9  scroll-bar: 16  divider: 0
  height header-line: 0  mode-line: 0  divider: 0


Here is the result for the *good* frame:

  frame pixel: 756 x 669   cols/lines: 84 x 37   units: 9 x 18
  frame text pixel: 720 x 667   cols/lines: 80 x 37
  tool: 36  scroll: 16  fringe: 18  border: 1  right: 0  bottom: 0

  #<window 3 on dev>   parent: nil
  pixel left: 0   top: 36   size: 754 x 613   new: 0
  char left: 0   top: 2   size: 83 x 34   new: 0
  normal: 1.0 x 1.0   new: 0
  body pixel: 720 x 595   char: 80 x 33
  width left fringe: 9  left margin: 0  right margin: 0
  width right fringe: 9  scroll-bar: 16  divider: 0
  height header-line: 0  mode-line: 18  divider: 0

  #<window 4 on  *Minibuf-0*>   parent: nil
  pixel left: 0   top: 649   size: 754 x 18   new: 0
  char left: 0   top: 36   size: 754 x 1   new: 0
  normal: 1.0 x 1.0   new: 0
  body pixel: 720 x 18   char: 80 x 1
  width left fringe: 9  left margin: 0  right margin: 0
  width right fringe: 9  scroll-bar: 16  divider: 0
  height header-line: 0  mode-line: 0  divider: 0


-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Mon, 03 Nov 2014 16:58:26 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> martin rudalics wrote:
> > Bruno: Could you please post the results of evaluating
> > 
> > (window--dump-frame)
> > 
> > here.  The results are in a buffer called *window-frame-dump*.  Please
> > do it for the good and the corrupted frame.
> 
> Here is the result for the *corrupted* frame:

They are identical.  But your original report stated that the
corrupted frame was 1 pixel taller, right?  Where's that pixel now?

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:
> They are identical.  But your original report stated that the
> corrupted frame was 1 pixel taller, right?  Where's that pixel now?

If Emacs is informing the frame's height consistently for both
procedures I'm afraid I don't know.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[martin rudalics]

 > Here is the result for the *corrupted* frame:
 >
 >    frame pixel: 756 x 669   cols/lines: 84 x 37   units: 9 x 18
 >    frame text pixel: 720 x 667   cols/lines: 80 x 37
 >    tool: 36  scroll: 16  fringe: 18  border: 1  right: 0  bottom: 0
 >
 >    #<window 3 on dev>   parent: nil
 >    pixel left: 0   top: 36   size: 754 x 613   new: 0
                                            ^^^
					
This is consistent with what you reported earlier, namely

   Bad configuration (both VGA1 and LVDS1 enabled):

   (window-height) ==> 34
   (window-pixel-height) ==> 613

 >    char left: 0   top: 2   size: 83 x 34   new: 0
 >    normal: 1.0 x 1.0   new: 0
 >    body pixel: 720 x 595   char: 80 x 33
 >    width left fringe: 9  left margin: 0  right margin: 0
 >    width right fringe: 9  scroll-bar: 16  divider: 0
 >    height header-line: 0  mode-line: 18  divider: 0
 >
 >    #<window 4 on  *Minibuf-0*>   parent: nil
 >    pixel left: 0   top: 649   size: 754 x 18   new: 0
 >    char left: 0   top: 36   size: 754 x 1   new: 0
 >    normal: 1.0 x 1.0   new: 0
 >    body pixel: 720 x 18   char: 80 x 1
 >    width left fringe: 9  left margin: 0  right margin: 0
 >    width right fringe: 9  scroll-bar: 16  divider: 0
 >    height header-line: 0  mode-line: 0  divider: 0
 >
 >
 > Here is the result for the *good* frame:
 >
 >    frame pixel: 756 x 669   cols/lines: 84 x 37   units: 9 x 18
 >    frame text pixel: 720 x 667   cols/lines: 80 x 37
 >    tool: 36  scroll: 16  fringe: 18  border: 1  right: 0  bottom: 0
 >
 >    #<window 3 on dev>   parent: nil
 >    pixel left: 0   top: 36   size: 754 x 613   new: 0
                                            ^^^

This is not consistent with what you reported earlier, namely

   Good configuration (only VGA1 enabled):

   (window-height) => 34
   (window-pixel-height) => 612

 >    char left: 0   top: 2   size: 83 x 34   new: 0
 >    normal: 1.0 x 1.0   new: 0
 >    body pixel: 720 x 595   char: 80 x 33
 >    width left fringe: 9  left margin: 0  right margin: 0
 >    width right fringe: 9  scroll-bar: 16  divider: 0
 >    height header-line: 0  mode-line: 18  divider: 0
 >
 >    #<window 4 on  *Minibuf-0*>   parent: nil
 >    pixel left: 0   top: 649   size: 754 x 18   new: 0
 >    char left: 0   top: 36   size: 754 x 1   new: 0
 >    normal: 1.0 x 1.0   new: 0
 >    body pixel: 720 x 18   char: 80 x 1
 >    width left fringe: 9  left margin: 0  right margin: 0
 >    width right fringe: 9  scroll-bar: 16  divider: 0
 >    height header-line: 0  mode-line: 0  divider: 0

Can you try getting the results of `window--dump-frame' for these old
(good and bad) configurations, that is with the build you used in your
initial report?  I'd want to see different pixel heights (not 669) for
these two frames but can't tell anything unless the pixel height (612)
of the good window reemerges.

So try first to get the different (window-pixel-height) values back and
then evaluate (window--dump-frame) instead of (window-pixel-height).

Thanks, martin

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

martin rudalics wrote:
> Can you try getting the results of `window--dump-frame' for these old
> (good and bad) configurations, that is with the build you used in your
> initial report?  I'd want to see different pixel heights (not 669) for
> these two frames but can't tell anything unless the pixel height (612)
> of the good window reemerges.
> 
> So try first to get the different (window-pixel-height) values back and
> then evaluate (window--dump-frame) instead of (window-pixel-height).

Trying to get the offending value back I figured out that the window
manager resizes the frame by one pixel when I move the frame from the
left side to the right one.  So, my original report was based on a
spurious intervention of the window manager.  Not moving the frame and
evaluating '(window-pixel-height)' results in the expected value of 613
for the *good* frame.  Sorry for the erroneous report.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[martin rudalics]

 > Trying to get the offending value back I figured out that the window
 > manager resizes the frame by one pixel when I move the frame from the
 > left side to the right one.

I don't understand what "moving the frame" means.  Does "left side" mean
VGA1 and "right side" LVDS1?  What evidence do you have that the window
manager "resizes" the frame when you move it?

 > So, my original report was based on a
 > spurious intervention of the window manager.  Not moving the frame and
 > evaluating '(window-pixel-height)' results in the expected value of 613
 > for the *good* frame.

And you get the corrupted mode line when you do "not move" the frame as
well?  Elsewhere you asked to "please, provide a way to make Emacs
optionally redraw the mode-line after any scroll operation".  How does
scrolling enter here?  Do you have to scroll the window in order to show
the corruption?  Maybe you could give us a step-by-step scenario of what
you do to the show the corruption, how to remove it afterwards, and how
to show it again after it was temporarily removed.

I don't have the slightest idea why the mode line would _not_ be redrawn
after scrolling but maybe there's some optimization here.  In any case
with emacs -Q moving the window's point from one line to another should
redraw the mode line to show the new line number.

BTW, suppose you evaluate

(set-frame-parameter nil 'bottom-divider-width 8)

Does that impact the appearance of the bug in any way?

martin

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

martin rudalics wrote:

> I don't understand what "moving the frame" means.  Does "left side" 
> mean VGA1 and "right side" LVDS1?

No.  When the frame is shown it has its left border touching the left
extremity of the VGA1 output, so by "moving the frame to the right
side" I meant moving the frame horizontally to the right until its
right border touches the right extremity of the VGA1 output.

> What evidence do you have that the window manager "resizes" the frame
> when you move it?

'xwininfo' tool reports the frame had 697 pixels of height before the
move, but 696 afterwards.

> And you get the corrupted mode line when you do "not move" the frame
> as well?

Yes, I do.  However, the frame 696 pixels tall doesn't corrupt the
mode-line, as shown by previous experiments.  A full-screen frame
corrupts it, though.

> Elsewhere you asked to "please, provide a way to make Emacs 
> optionally redraw the mode-line after any scroll operation".  How 
> does scrolling enter here?

After getting the mode-line right by refreshing the frame, only
scrolling can possibly corrupt the mode-line again.

> Do you have to scroll the window in order to show the corruption?

If the frame was refreshed, yes.

> Maybe you could give us a step-by-step scenario of what you do to the
> show the corruption, how to remove it afterwards, and how to show it
> again after it was temporarily removed.

After creating the frame with 'emacs -Q', typing 'C-x d /dev RET'
takes me to a Dired buffer with a corrupted mode-line as shown in the
picture attached to the original bug report.  There, typing 'M-!
xrefresh RET' repaints the whole frame and the mode-line is shown
normally as one would expect.  Scrolling the text up with 'C-v'
corrupts the mode-line again.

> I don't have the slightest idea why the mode line would _not_ be
> redrawn after scrolling but maybe there's some optimization here.  In
> any case with emacs -Q moving the window's point from one line to
> another should redraw the mode line to show the new line number.

If it redraws the mode-line, it does so while corrupting the mode-line
again, because, by observation, updating the line number doesn't
trigger the same kind of redraw that the 'xrefresh' command does.

> BTW, suppose you evaluate
> 
> (set-frame-parameter nil 'bottom-divider-width 8)
> 
> Does that impact the appearance of the bug in any way?

Yes, it does.  The mode-line still gets corrupt but this time by the
lower half (approximately) of the line above the one that corrupted it
originally.

Interesting enough,

(set-frame-parameter nil 'bottom-divider-width 1)

fixes the problem for the original frame.  Unfortunately when
in full-screen the mode-line is corrupted again; what is fixed in the
VGA1 output by

(set-frame-parameter nil 'bottom-divider-width 7)

and in the LVDS1 output by

(set-frame-parameter nil 'bottom-divider-width 12)

I'd miss some useful screen area, though.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii]

> Date: Tue, 04 Nov 2014 08:25:38 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> > Elsewhere you asked to "please, provide a way to make Emacs 
> > optionally redraw the mode-line after any scroll operation".  How 
> > does scrolling enter here?
> 
> After getting the mode-line right by refreshing the frame, only
> scrolling can possibly corrupt the mode-line again.

What do you mean by "scrolling", exactly?  Which Emacs commands?

In any case, the initial display of "C-x d" doesn't involve any
scrolling, so it's not a "scrolling problem".

> After creating the frame with 'emacs -Q', typing 'C-x d /dev RET'
> takes me to a Dired buffer with a corrupted mode-line as shown in the
> picture attached to the original bug report.  There, typing 'M-!
> xrefresh RET' repaints the whole frame and the mode-line is shown
> normally as one would expect.  Scrolling the text up with 'C-v'
> corrupts the mode-line again.

What about moving cursor so it exits the visible portion of the
window, which also induces scrolling?  And what about using the scroll
bar?  Or just "M-x goto-char RET"?  Are you saying these don't produce
a corrupted mode line?

> > I don't have the slightest idea why the mode line would _not_ be
> > redrawn after scrolling but maybe there's some optimization here.  In
> > any case with emacs -Q moving the window's point from one line to
> > another should redraw the mode line to show the new line number.
> 
> If it redraws the mode-line, it does so while corrupting the mode-line
> again

When you move to a different line, Emacs only redraws the line number
part of the mode line.  Does that at least remove the corruption in
that area, or doesn't it?

In general, Emacs always redraws only the parts of the screen that
were changed.  If you tell it to redraw, and nothing changed, it will
normally not redraw anything at all.

> because, by observation, updating the line number doesn't trigger
> the same kind of redraw that the 'xrefresh' command does.

Of course, it doesn't!  Emacs doesn't use the technique used by
xrefresh, because Emacs tries to redraw as little as possible, not as
much as possible!  xrefresh was coded specifically to force portions
of the screen to be completely redrawn, which is almost the
anti-thesis of the Emacs display engine.

Is there _any_ Emacs action that succeeds in redrawing the mode line
or its parts in a way that eliminates the corruption?  I already asked
above about whether moving to a different line does that in the
portion that displays the line number.  How about hovering the mouse
pointer over mouse-sensitive portions of the mode line, like the
buffer name and the major/minor mode indications? do they successfully
redraw the corresponding parts of the mode line?

What about "M-x redraw-display RET" -- does it fix the display of the
mode line?

If none of these helps, then I don't think Emacs can do anything at
all to help you work around the problem.

(And btw, why disabling the acceleration permanently isn't _the_
solution?)

> > BTW, suppose you evaluate
> > 
> > (set-frame-parameter nil 'bottom-divider-width 8)
> > 
> > Does that impact the appearance of the bug in any way?
> 
> Yes, it does.  The mode-line still gets corrupt but this time by the
> lower half (approximately) of the line above the one that corrupted it
> originally.
> 
> Interesting enough,
> 
> (set-frame-parameter nil 'bottom-divider-width 1)
> 
> fixes the problem for the original frame.  Unfortunately when
> in full-screen the mode-line is corrupted again; what is fixed in the
> VGA1 output by
> 
> (set-frame-parameter nil 'bottom-divider-width 7)
> 
> and in the LVDS1 output by
> 
> (set-frame-parameter nil 'bottom-divider-width 12)

Any change in window height that causes it to be an exact integral
multiple of the font height will eliminate the problem.  The problem
is evidently caused by incorrect clipping of partially-visible lines.
That's why you see what you see.

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

Eli Zaretskii wrote:

> What do you mean by "scrolling", exactly?  Which Emacs commands?

I mean by scroll the change of correspondence between window lines and
buffer lines.  It's not absolutely associated with any particular
Emacs command.  There are commands that are intended to directly cause
scrolling, but don't do so in particular cases (eg. 'C-v' at the
end of the buffer), and there are commands that are not directly
intended to cause scrolling but do so in particular cases
(eg. 'C-n' at the last visible line of a window).

> In any case, the initial display of "C-x d" doesn't involve any 
> scrolling, so it's not a "scrolling problem".

You are right.  That's a particular case for which the rule of thumb
is: for newly created windows the mode-line should be drawn after the
buffer's content is drawn.  I think that would solve the problem.
From there forth, after any scrolling the mode-line should be
(optionally) drawn after the buffer's content is drawn.

> What about moving cursor so it exits the visible portion of the 
> window, which also induces scrolling?

It corrupts the mode-line as do 'C-l' typed multiple times.

> And what about using the scroll bar?

This too.

> Or just "M-x goto-char RET"?

Idem, as long as it causes scrolling and the new view has a buffer
line "under" the mode-line.  The same happens with the 'goto-line'
command.

> Are you saying these don't produce a corrupted mode line?

Nope, actually all of them are capable of corrupting the mode-line.

> When you move to a different line, Emacs only redraws the line number
> part of the mode line.  Does that at least remove the corruption in
> that area, or doesn't it?

It does in that very area.

> In general, Emacs always redraws only the parts of the screen that 
> were changed.  If you tell it to redraw, and nothing changed, it will
> normally not redraw anything at all.

It would be wise to provide a way to force Emacs to redraw, because
there are factors beyond Emacs control and knowledge that could change
the aspect of the frame.  This bug is an example of that.

> Of course, it doesn't!  Emacs doesn't use the technique used by 
> xrefresh, because Emacs tries to redraw as little as possible, not as
> much as possible!  xrefresh was coded specifically to force portions
> of the screen to be completely redrawn, which is almost the 
> anti-thesis of the Emacs display engine.

Again, sometimes it's necessary to redraw more than Emacs think it
should.  I'm not advocating to make Emacs redraw the whole frame,
rather just the mode-line after very specific events.

> Is there _any_ Emacs action that succeeds in redrawing the mode line
>  or its parts in a way that eliminates the corruption?

Yes, there is.

> I already asked above about whether moving to a different line does 
> that in the portion that displays the line number.  How about 
> hovering the mouse pointer over mouse-sensitive portions of the mode
>  line, like the buffer name and the major/minor mode indications?

This also eliminates the corruption.

> do they successfully redraw the corresponding parts of the mode 
> line?

Yep.

> What about "M-x redraw-display RET" -- does it fix the display of the
> mode line?

Nope, because it draws the buffer's content after redrawing the
mode-line, overriding the mode-line refresh, in effect.

> If none of these helps, then I don't think Emacs can do anything at 
> all to help you work around the problem.

They in fact help!  So I think Emacs can do something to help me work
around the problem, if you help Emacs to help me. ;-)

> (And btw, why disabling the acceleration permanently isn't _the_ 
> solution?)

Because the acceleration is not intended to cause that sort of
problem.  That's bug.  Moreover, if I disable acceleration I would
affect a lot more than just Emacs.  On the other hand, the Emacs
workaround I propose won't affect any other application or user of
Emacs, and will help everyone else experiencing similar problems.

From my perspective, it's an improvement to make Emacs aware that it
cannot know everything, and therefore we reserve the right to force it
to redraw some parts of its frames, even if it doesn't feel like it,
when we, the users, judge necessary.

In particular Emacs must know that when redrawing the frame's content,
it should first draw the buffer's content and only then the mode-line.

> Any change in window height that causes it to be an exact integral 
> multiple of the font height will eliminate the problem.  The problem
>  is evidently caused by incorrect clipping of partially-visible 
> lines. That's why you see what you see.

That makes a lot of sense.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[martin rudalics]

 > 'xwininfo' tool reports the frame had 697 pixels of height before the
 > move, but 696 afterwards.

A frame move should never resize the frame.  Apparently the size hints
are working here.  Does it resize when you set `frame-resize-pixelwise'
permanently to nil too?  As an aside: IIRC trusting the values reported
by xwininfo is just like trusting any values reported by Emacs - they
are partially based on what is written into the size hints.

 > Yes, I do.  However, the frame 696 pixels tall doesn't corrupt the
 > mode-line, as shown by previous experiments.  A full-screen frame
 > corrupts it, though.

And all other sizes that are not an integral multiple of the default
character size, I presume.  But when you split a window via C-x 2 and
mouse-drag the mode line of the upper window by very small (pixel)
increments do you see any corruption too?

 > After getting the mode-line right by refreshing the frame, only
 > scrolling can possibly corrupt the mode-line again.
 >
 >> Do you have to scroll the window in order to show the corruption?
 >
 > If the frame was refreshed, yes.

But you get the corruption only in a fullsized frame?

 >> Maybe you could give us a step-by-step scenario of what you do to the
 >> show the corruption, how to remove it afterwards, and how to show it
 >> again after it was temporarily removed.
 >
 > After creating the frame with 'emacs -Q',

Don't you have to make the frame fullsize here?

 > typing 'C-x d /dev RET'
 > takes me to a Dired buffer with a corrupted mode-line as shown in the
 > picture attached to the original bug report.  There, typing 'M-!
 > xrefresh RET' repaints the whole frame and the mode-line is shown
 > normally as one would expect.  Scrolling the text up with 'C-v'
 > corrupts the mode-line again.

How does scrolling an upper window in a split frame work in this case?

martin

bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Bruno Félix Rezende Ribeiro]

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

martin rudalics wrote

> A frame move should never resize the frame.  Apparently the size
> hints are working here.  Does it resize when you set
> `frame-resize-pixelwise' permanently to nil too?

In fact it was originally reported in that case, as Emacs was started
by 'emacs -Q', and by default 'frame-resize-pixelwise' is 'nil'.

> And all other sizes that are not an integral multiple of the default 
> character size, I presume.  But when you split a window via C-x 2
> and mouse-drag the mode line of the upper window by very small
> (pixel) increments do you see any corruption too?

Yes, I do, as described here [0].

> But you get the corruption only in a fullsized frame?

Nope, I presume I do in all frames whose height is not an integral
multiple of the default character size.

> Don't you have to make the frame fullsize here?

No, I don't.

> How does scrolling an upper window in a split frame work in this
> case?

It works the same: corrupted mode-line for the upper window.


Footnotes:

[0] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18912#149


-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]