bug#33971: artifacts on screen in 26.1

bug#33971: artifacts on screen in 26.1

[積丹尼 Dan Jacobson]

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.

bug#33971: artifacts on screen in 26.1

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
> 	<jidanni@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.

bug#33971: artifacts on screen in 26.1

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@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.

bug#33971: artifacts on screen in 26.1

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: 33971@debbugs.gnu.org
> Date: Fri, 04 Jan 2019 17:46:33 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@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.

bug#33971: artifacts on screen in 26.1

[積丹尼 Dan Jacobson]

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

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.


[-- Attachment #2: BAD --]
[-- Type: image/jpeg, Size: 135405 bytes --]

[-- Attachment #3: GOOD --]
[-- Type: image/jpeg, Size: 127472 bytes --]

bug#33971: artifacts on screen in 26.1

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: 33971@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?

bug#33971: artifacts on screen in 26.1

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@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" ?)

bug#33971: artifacts on screen in 26.1

[Lars Ingebrigtsen]

積丹尼 Dan Jacobson <jidanni@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

bug#33971: artifacts on screen in 26.1

[積丹尼 Dan Jacobson]

>>>>> "LI" == Lars Ingebrigtsen <larsi@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.