bug#21658: 24.5; Scrolling garbles text with third monitor enabled

bug#21658: 24.5; Scrolling garbles text with third monitor enabled

[me]

When I scroll a buffer with the mouse in GTK3, GTK2, or lucid emacs, the
buffer does not properly redraw, causing garbled text.  With the mouse
scroll, it usually appears like the text is not moving (even though the
point is actually moving).  If I scroll with keyboard controls, the
buffer partially redraws, usually in a ~32 character square with the
point at the upper left.  The screen will redraw correctly if (1) Emacs
loses focus or (2) I recenter the buffer with C-l.

This only happens when my third monitor is enabled, however.  On my
system, I have two monitors attached to the onboard Intel GPU, and one
additional attached to an AMD GPU card.  It makes no difference what
monitor emacs is on, but enabling the monitor on the AMD GPU causes
emacs to behave as described.  Disabling the monitor (via xrandr)
immediately fixes the problem.

I do not observe this problem with any other software on my system, only
emacs.


In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.6)
 of 2015-09-09 on foutrelis
Windowing system distributor `The X.Org Foundation', version 11.0.11702000
System Description:	Arch Linux

Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date 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 move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 71762 6138)
 (symbols 48 17554 0)
 (miscs 40 35 138)
 (strings 32 9829 4741)
 (string-bytes 1 268333)
 (vectors 16 8908)
 (vector-slots 8 383094 18351)
 (floats 8 63 172)
 (intervals 56 177 3)
 (buffers 960 11)
 (heap 1024 31637 1056))

bug#21658: 24.5; Scrolling garbles text with third monitor enabled

[Eli Zaretskii]

> Date: Fri, 9 Oct 2015 18:31:14 -0000 (GMT)
> From: me@alandmoore.com
> 
> When I scroll a buffer with the mouse in GTK3, GTK2, or lucid emacs, the
> buffer does not properly redraw, causing garbled text.  With the mouse
> scroll, it usually appears like the text is not moving (even though the
> point is actually moving).  If I scroll with keyboard controls, the
> buffer partially redraws, usually in a ~32 character square with the
> point at the upper left.  The screen will redraw correctly if (1) Emacs
> loses focus or (2) I recenter the buffer with C-l.
> 
> This only happens when my third monitor is enabled, however.  On my
> system, I have two monitors attached to the onboard Intel GPU, and one
> additional attached to an AMD GPU card.  It makes no difference what
> monitor emacs is on, but enabling the monitor on the AMD GPU causes
> emacs to behave as described.  Disabling the monitor (via xrandr)
> immediately fixes the problem.
> 
> I do not observe this problem with any other software on my system, only
> emacs.

Are the problematic frames/windows displayed on the 3rd monitor?

Do the coordinates of the frames on the 1st and the 2nd monitor change
when you enable the 3rd monitor?

If the answer to both of these questions is NO, then I cannot see how
it could be an Emacs problem.  It could be some hardware problem or
perhaps a bug in the underlying X libraries/server.  AFAIK, when Emacs
redraws a window on a monitor, it doesn't inquire the system about the
monitors, the only thing it cares about is pixel coordinates of
windows and frames.

bug#21658: 24.5; Scrolling garbles text with third monitor enabled

[Eli Zaretskii]

[Please keep the bug address on the CC list.]

> Date: Mon, 12 Oct 2015 18:21:08 -0000 (GMT)
> From: me@alandmoore.com
> 
> > Are the problematic frames/windows displayed on the 3rd monitor?
> >
> > Do the coordinates of the frames on the 1st and the 2nd monitor change
> > when you enable the 3rd monitor?
> >
> > If the answer to both of these questions is NO, then I cannot see how
> > it could be an Emacs problem.  It could be some hardware problem or
> > perhaps a bug in the underlying X libraries/server.  AFAIK, when Emacs
> > redraws a window on a monitor, it doesn't inquire the system about the
> > monitors, the only thing it cares about is pixel coordinates of
> > windows and frames.
> >
> 
> The frames do the same thing on any monitor.  I don't think the
> coordinates should change at all, the additional monitor is appended to
> the right of the others (though it makes no difference where I add it,
> even if I just clone one of the other screens).
> 
> Is there anything special about the way emacs buffers are drawn compared
> to other programs that would give me a clue as to why this only happens in
> emacs?

We just use Xlib calls, see xterm.c and xfns.c.

bug#21658: 24.5; Scrolling garbles text with third monitor enabled

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 9 Oct 2015 18:31:14 -0000 (GMT)
>> From: me@alandmoore.com
>>
>> When I scroll a buffer with the mouse in GTK3, GTK2, or lucid emacs, the
>> buffer does not properly redraw, causing garbled text.  With the mouse
>> scroll, it usually appears like the text is not moving (even though the
>> point is actually moving).  If I scroll with keyboard controls, the
>> buffer partially redraws, usually in a ~32 character square with the
>> point at the upper left.  The screen will redraw correctly if (1) Emacs
>> loses focus or (2) I recenter the buffer with C-l.
>>
>> This only happens when my third monitor is enabled, however.  On my
>> system, I have two monitors attached to the onboard Intel GPU, and one
>> additional attached to an AMD GPU card.  It makes no difference what
>> monitor emacs is on, but enabling the monitor on the AMD GPU causes
>> emacs to behave as described.  Disabling the monitor (via xrandr)
>> immediately fixes the problem.
>>
>> I do not observe this problem with any other software on my system, only
>> emacs.
>
> Are the problematic frames/windows displayed on the 3rd monitor?
>
> Do the coordinates of the frames on the 1st and the 2nd monitor change
> when you enable the 3rd monitor?
>
> If the answer to both of these questions is NO, then I cannot see how
> it could be an Emacs problem.  It could be some hardware problem or
> perhaps a bug in the underlying X libraries/server.  AFAIK, when Emacs
> redraws a window on a monitor, it doesn't inquire the system about the
> monitors, the only thing it cares about is pixel coordinates of
> windows and frames.

More information was requested but none given within close to 4 years.
It will therefore be hard to make any progress here, and I'm closing
this bug report.  If this is still an issue, please reopen the bug.

Best regards,
Stefan Kangas