GNU bug report logs - #33971
artifacts on screen in 26.1

Previous Next

Package: emacs;

Reported by: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>

Date: Fri, 4 Jan 2019 02:52:01 UTC

Severity: minor

Tags: moreinfo

Done: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>

Bug is archived. No further changes may be made.

Full log


Message #23 received at 33971 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 33971 <at> debbugs.gnu.org
Subject: Re: bug#33971: artifacts on screen in 26.1
Date: Mon, 07 Jan 2019 08:50:13 +0800
>>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
>> then pressing three right or left arrows (cursor movement), or one up or
>> one down arrow clears it

EZ> You mean, a small cursor motion clears _all_ of the artifacts in the
EZ> entire window, not just where you move the cursor?

Yup.

>> A single CTRL+L doesn't always clear it.

EZ> C-l on a GUI frame doesn't by default redraw the frame in recent
EZ> versions of Emacs.  You need to invoke "M-x redraw-display RET" for
EZ> that, or "M-x recenter RET" after setting recenter-redisplay to t.

(Indeed, all I need to type is the "M-x" (ESC x for old me) and it clears
the problem.)

>> It only affects my 32 bit fifteen year old Thinkpad R50e, so emacs 26.1
>> is going too fast, not confirming each rendering step has completed or
>> something.

EZ> There's no such confirmation, and none is really possible AFAIK.
EZ> Emacs just trusts the X server to do what it's being told to do.
EZ> There's no reason for Emacs not to trust the X server.

EZ> When Emacs redisplays a window, it only draws in the portions of the
EZ> window that should be different from the previously displayed stuff,
EZ> deleting the old stuff where there should be whitespace instead of
EZ> text.  In your case, this deletion seems to not be working, for some
EZ> reason, but that cannot normally be Emacs's fault.

Well all I know is it happens about 20% of the time switching between
gnus messages, and 5% of the time switching dired screens, and nowhere else.

EZ> You didn't show your build configuration, so I don't know: does this
EZ> build use Cairo?  If so, try a non-Cairo build instead.

$ reportbug --template emacs-gtk 2>&1|grep cairo
ii  libcairo-gobject2      1.16.0-2
ii  libcairo2              1.16.0-2
ii  libpangocairo-1.0-0    1.42.4-6

EZ> Other than glitches in a Cairo build, we are not aware of such glaring
EZ> problems in Emacs display, including on old machines.  If Cairo is not
EZ> involved, I still think this is something related to your system's
EZ> display software.  Did you try looking up the video driver settings
EZ> and disabling its optimizations features?

I think Debian only has one build, and me messing with video drivers... scary...

I can confirm
(info "(emacs) Table of Resources")
Emacs.synchronous:on
didn't help.

But wait,

‘-D’
‘--basic-display’
     Disable the menu-bar, the tool-bar, the scroll-bars, and tool tips,
     and turn off the blinking cursor.  This can be useful for making a
     test case that simplifies debugging of display problems.

on (info "(emacs) Misc X") fixes the problem 100%, and seems a small
price to pay! I sure wish I could somehow put it into my .emacs file. (Or can I only bash alias emacs="emacs -D" ?)





This bug report was last modified 4 years and 338 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.