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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33971 in the body.
You can then email your comments to 33971 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-gnu-emacs <at> gnu.org
Subject: artifacts on screen in 26.1
Date: Fri, 04 Jan 2019 10:51:31 +0800

Now with emacs-version "26.1" I often see artifacts, e.g.
From:aBobxDobbs <...
Date:qMon....
(so far in gnus, and dired,)
on the screen, but they go away when I try to take a sceenshot of them,
-- in fact whenever I take any keyboard action, so I can't send you a
screenshot, nor have I found a way to reproduce them.
So just letting you know.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 33971 <at> debbugs.gnu.org
Subject: Re: bug#33971: artifacts on screen in 26.1
Date: Fri, 04 Jan 2019 09:03:14 +0200

> From: 積丹尼 Dan Jacobson
> 	<jidanni <at> jidanni.org>
> Date: Fri, 04 Jan 2019 10:51:31 +0800
> 
> Now with emacs-version "26.1" I often see artifacts, e.g.
> From:aBobxDobbs <...
> Date:qMon....
> (so far in gnus, and dired,)
> on the screen, but they go away when I try to take a sceenshot of them,
> -- in fact whenever I take any keyboard action, so I can't send you a
> screenshot, nor have I found a way to reproduce them.
> So just letting you know.

Try changing the settings of your video driver to less aggressive
ones.

Message #11 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: Fri, 04 Jan 2019 17:46:33 +0800

>>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
EZ> Try changing the settings of your video driver to less aggressive
EZ> ones.
I was just about to take a picture of it with my cellphone camera,
but then something updated the screen and made it go away. So it only
lasts a total of 15 seconds max.

Anyway it only started with emacs 26, and no other programs have this
problem, so any "aggressive video settings" that I haven't ever tinkered
with probably aren't the problem.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 33971 <at> debbugs.gnu.org
Subject: Re: bug#33971: artifacts on screen in 26.1
Date: Fri, 04 Jan 2019 15:08:05 +0200

> From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
> Cc: 33971 <at> debbugs.gnu.org
> Date: Fri, 04 Jan 2019 17:46:33 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
> EZ> Try changing the settings of your video driver to less aggressive
> EZ> ones.
> I was just about to take a picture of it with my cellphone camera,
> but then something updated the screen and made it go away. So it only
> lasts a total of 15 seconds max.
> 
> Anyway it only started with emacs 26, and no other programs have this
> problem, so any "aggressive video settings" that I haven't ever tinkered
> with probably aren't the problem.

I was guessing.  Without any way of seeing what you see, it's hard to
do more than just guess.

And your assumption that this must be an Emacs problem given the
symptoms is not necessarily correct.  I've seen such problems becoming
visible only in Emacs.

Message #17 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: Sat, 05 Jan 2019 06:25:56 +0800

[Message part 1 (text/plain, inline)]

OK, I was able to capture it with
$ sleep 22; import -window root bad.jpg
then pressing three right or left arrows (cursor movement), or one up or
one down arrow clears it, and I then made good.jpg. A single CTRL+L
doesn't always clear it.

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.

[bad.jpg (image/jpeg, attachment)]

[good.jpg (image/jpeg, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 33971 <at> debbugs.gnu.org
Subject: Re: bug#33971: artifacts on screen in 26.1
Date: Sat, 05 Jan 2019 08:49:11 +0200

> From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
> Cc: 33971 <at> debbugs.gnu.org
> Date: Sat, 05 Jan 2019 06:25:56 +0800
> 
> OK, I was able to capture it with
> $ sleep 22; import -window root bad.jpg

Thanks.

> then pressing three right or left arrows (cursor movement), or one up or
> one down arrow clears it

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

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

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

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

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

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

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

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

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 33971 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#33971: artifacts on screen in 26.1
Date: Fri, 07 Aug 2020 10:46:30 +0200

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

> OK, I was able to capture it with
> $ sleep 22; import -window root bad.jpg
> then pressing three right or left arrows (cursor movement), or one up or
> one down arrow clears it, and I then made good.jpg. A single CTRL+L
> doesn't always clear it.
>
> 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.

Are you still seeing this problem in more recent versions of Emacs?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 33971-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#33971: artifacts on screen in 26.1
Date: Sun, 09 Aug 2020 14:03:31 +0800

>>>>> "LI" == Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> It only affects my 32 bit fifteen year old Thinkpad R50e

LI> Are you still seeing this problem in more recent versions of Emacs?

Hmmm, I sold it for two bucks to the junk man, so will close this.

Previous Next

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