* bug#33971: artifacts on screen in 26.1 @ 2019-01-04 2:51 積丹尼 Dan Jacobson 2019-01-04 7:03 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: 積丹尼 Dan Jacobson @ 2019-01-04 2:51 UTC (permalink / raw) To: 33971 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#33971: artifacts on screen in 26.1 2019-01-04 2:51 bug#33971: artifacts on screen in 26.1 積丹尼 Dan Jacobson @ 2019-01-04 7:03 ` Eli Zaretskii 2019-01-04 9:46 ` 積丹尼 Dan Jacobson 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2019-01-04 7:03 UTC (permalink / raw) To: 積丹尼 Dan Jacobson; +Cc: 33971 > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#33971: artifacts on screen in 26.1 2019-01-04 7:03 ` Eli Zaretskii @ 2019-01-04 9:46 ` 積丹尼 Dan Jacobson 2019-01-04 13:08 ` Eli Zaretskii 0 siblings, 1 reply; 9+ messages in thread From: 積丹尼 Dan Jacobson @ 2019-01-04 9:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 33971 >>>>> "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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#33971: artifacts on screen in 26.1 2019-01-04 9:46 ` 積丹尼 Dan Jacobson @ 2019-01-04 13:08 ` Eli Zaretskii 2019-01-04 22:25 ` 積丹尼 Dan Jacobson 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2019-01-04 13:08 UTC (permalink / raw) To: 積丹尼 Dan Jacobson; +Cc: 33971 > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#33971: artifacts on screen in 26.1 2019-01-04 13:08 ` Eli Zaretskii @ 2019-01-04 22:25 ` 積丹尼 Dan Jacobson 2019-01-05 6:49 ` Eli Zaretskii 2020-08-07 8:46 ` Lars Ingebrigtsen 0 siblings, 2 replies; 9+ messages in thread From: 積丹尼 Dan Jacobson @ 2019-01-04 22:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 33971 [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#33971: artifacts on screen in 26.1 2019-01-04 22:25 ` 積丹尼 Dan Jacobson @ 2019-01-05 6:49 ` Eli Zaretskii 2019-01-07 0:50 ` 積丹尼 Dan Jacobson 2020-08-07 8:46 ` Lars Ingebrigtsen 1 sibling, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2019-01-05 6:49 UTC (permalink / raw) To: 積丹尼 Dan Jacobson; +Cc: 33971 > 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#33971: artifacts on screen in 26.1 2019-01-05 6:49 ` Eli Zaretskii @ 2019-01-07 0:50 ` 積丹尼 Dan Jacobson 0 siblings, 0 replies; 9+ messages in thread From: 積丹尼 Dan Jacobson @ 2019-01-07 0:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 33971 >>>>> "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" ?) ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#33971: artifacts on screen in 26.1 2019-01-04 22:25 ` 積丹尼 Dan Jacobson 2019-01-05 6:49 ` Eli Zaretskii @ 2020-08-07 8:46 ` Lars Ingebrigtsen 2020-08-09 6:03 ` 積丹尼 Dan Jacobson 1 sibling, 1 reply; 9+ messages in thread From: Lars Ingebrigtsen @ 2020-08-07 8:46 UTC (permalink / raw) To: 積丹尼 Dan Jacobson; +Cc: 33971 積丹尼 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#33971: artifacts on screen in 26.1 2020-08-07 8:46 ` Lars Ingebrigtsen @ 2020-08-09 6:03 ` 積丹尼 Dan Jacobson 0 siblings, 0 replies; 9+ messages in thread From: 積丹尼 Dan Jacobson @ 2020-08-09 6:03 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 33971-done >>>>> "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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-08-09 6:03 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-01-04 2:51 bug#33971: artifacts on screen in 26.1 積丹尼 Dan Jacobson 2019-01-04 7:03 ` Eli Zaretskii 2019-01-04 9:46 ` 積丹尼 Dan Jacobson 2019-01-04 13:08 ` Eli Zaretskii 2019-01-04 22:25 ` 積丹尼 Dan Jacobson 2019-01-05 6:49 ` Eli Zaretskii 2019-01-07 0:50 ` 積丹尼 Dan Jacobson 2020-08-07 8:46 ` Lars Ingebrigtsen 2020-08-09 6:03 ` 積丹尼 Dan Jacobson
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).