emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#21658: closed (24.5; Scrolling garbles text with t


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#21658: closed (24.5; Scrolling garbles text with third monitor enabled)
Date: Sun, 29 Sep 2019 21:59:01 +0000

Your message dated Sun, 29 Sep 2019 23:58:38 +0200
with message-id <address@hidden>
and subject line Re: bug#21658: 24.5; Scrolling garbles text with third monitor 
enabled
has caused the debbugs.gnu.org bug report #21658,
regarding 24.5; Scrolling garbles text with third monitor enabled
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
21658: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21658
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.5; Scrolling garbles text with third monitor enabled Date: Fri, 9 Oct 2015 18:31:14 -0000 (GMT) User-agent: SquirrelMail/1.4.6
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))





--- End Message ---
--- Begin Message --- Subject: Re: bug#21658: 24.5; Scrolling garbles text with third monitor enabled Date: Sun, 29 Sep 2019 23:58:38 +0200
Eli Zaretskii <address@hidden> writes:

>> Date: Fri, 9 Oct 2015 18:31:14 -0000 (GMT)
>> From: address@hidden
>>
>> 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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]