GNU bug report logs -
#11070
24.0.94; Large stippled images not displayed consistently
Previous Next
To reply to this bug, email your comments to 11070 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Thu, 22 Mar 2012 21:44:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ivan Andrus <darthandrus <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 22 Mar 2012 21:44:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Starting with emacs -Q, change the path to an image that is taller than a line of text.
;; Evaluate this
(face-remap-add-relative 'default
'(:stipple "/path/to/large/image.jpg"))
;; Evaluate this once
(scroll-down -3)
;; Evaluate this 3 times
(scroll-down 1)
;; Notice that the top 3 lines now are repeated using the top portion
;; of the image.
;; Now evaluate these
(scroll-down -3)
(scroll-down 3)
;; Notice that the top 3 lines are now correct.
Also, sometimes moving point (especially with
`backward-paragraph' and `forward-paragraph') will cause lines to
change which portion of the image they display. This is a little
less predictable, but evaluating (scroll-down -3) and then
repeatedly using `backward-paragraph' will cause lines to change.
Then once the window scrolls to the top `forward-paragraph' will
cause them to change again.
It seems it may be related to when the cursor is at then end of a line.
Thanks,
Ivan Andrus
In GNU Emacs 24.0.94.6 (i386-apple-darwin10.8.0, NS apple-appkit-1038.36)
of 2012-03-19 on oroszlan.local
Windowing system distributor `Apple', version 10.3.1038
Configured using:
`configure '--with-ns' '-C''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: UTF-8
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
tooltip-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 input:
m M-q SPC t o SPC r e d i s p l a y SPC a g a i n .
<up> C-a <C-right> <C-left> C-d C-d c h a n g e SPC
t h e SPC i m a g <C-right> <C-backspace> <C-backspace>
<backspace> M-q <down> C-e <C-left> <C-backspace> c
h a n g e SPC M-q C-x C-s <C-up> <C-up> <C-up> <C-up>
<C-up> <C-up> <C-up> <C-up> <C-up> <down> C-e SPC -
- SPC C-x C-s <C-down> <C-down> <up> <up> <up> <up>
<C-right> <C-right> <C-left> <left> <down> C-x C-e
<up> <C-right> <C-right> <C-left> C-j <backspace> <left>
C-y C-u C-u C-u C-u <C-left> <down> <down> <down> <down>
<C-right> <C-right> <C-left> C-y C-d C-d C-d C-d C-d
C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d
C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d
C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d
C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d C-d
C-d C-d C-d C-d C-d C-d C-d C-d C-e C-x C-e C-/ C-/
C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/
C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/
C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/
C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/
C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/
C-/ <backspace> C-x C-s <C-down> C-x C-e <C-down> C-x
C-e <C-down> C-x C-e C-x C-e C-x C-e C-x C-e <C-down>
<C-down> C-x C-e <C-down> C-x C-e <C-up> <C-up> <C-up>
<C-up> <C-up> <C-up> <C-up> <C-down> <C-down> <C-down>
<C-down> <C-down> <C-down> <C-down> <C-down> <C-down>
C-x C-s M-x r e p o r <tab> <return>
Recent messages:
Undo! [23 times]
Auto-saving...
Undo! [45 times]
Saving file /Users/gvol/vcs/emacs/face-mapping-bug.el...
Wrote /Users/gvol/vcs/emacs/face-mapping-bug.el
(default :stipple "/Users/gvol/.emacs.d/local/pic/b-rock-grey.jpg")
nil [4 times]
eval: Beginning of buffer
nil [2 times]
(No changes need to be saved)
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 regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils dabbrev newcomment face-remap
vc-hg time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
ns-win tool-bar dnd fontset image fringe lisp-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 loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process ns multi-tty emacs)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Fri, 23 Mar 2012 11:02:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 11070 <at> debbugs.gnu.org (full text, mbox):
> From: Ivan Andrus <darthandrus <at> gmail.com>
> Date: Thu, 22 Mar 2012 22:12:28 +0100
>
> Starting with emacs -Q, change the path to an image that is taller than a line of text.
>
> ;; Evaluate this
> (face-remap-add-relative 'default
> '(:stipple "/path/to/large/image.jpg"))
>
> ;; Evaluate this once
> (scroll-down -3)
>
> ;; Evaluate this 3 times
> (scroll-down 1)
>
> ;; Notice that the top 3 lines now are repeated using the top portion
> ;; of the image.
>
> ;; Now evaluate these
> (scroll-down -3)
>
> (scroll-down 3)
>
> ;; Notice that the top 3 lines are now correct.
Please post an image file that can be used to reproduce this problem.
I'd like to avoid searching my disk for a suitable JPEG file.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Fri, 23 Mar 2012 11:33:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 11070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mar 23, 2012, at 11:30 AM, Eli Zaretskii wrote:
>> From: Ivan Andrus <darthandrus <at> gmail.com>
>> Date: Thu, 22 Mar 2012 22:12:28 +0100
>>
>> Starting with emacs -Q, change the path to an image that is taller than a line of text.
>>
>> ;; Evaluate this
>> (face-remap-add-relative 'default
>> '(:stipple "/path/to/large/image.jpg"))
>>
>> ;; Evaluate this once
>> (scroll-down -3)
>>
>> ;; Evaluate this 3 times
>> (scroll-down 1)
>>
>> ;; Notice that the top 3 lines now are repeated using the top portion
>> ;; of the image.
>>
>> ;; Now evaluate these
>> (scroll-down -3)
>>
>> (scroll-down 3)
>>
>> ;; Notice that the top 3 lines are now correct.
>
> Please post an image file that can be used to reproduce this problem.
> I'd like to avoid searching my disk for a suitable JPEG file.
>
> Thanks.
If attachments get stripped I have also uploaded it to http://i.imgur.com/UH7bc.jpg
-Ivan
[b-rock-grey.jpg (image/jpg, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Fri, 23 Mar 2012 16:35:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 11070 <at> debbugs.gnu.org (full text, mbox):
> From: Ivan Andrus <darthandrus <at> gmail.com>
> Date: Thu, 22 Mar 2012 22:12:28 +0100
>
> Starting with emacs -Q, change the path to an image that is taller than a line of text.
>
> ;; Evaluate this
> (face-remap-add-relative 'default
> '(:stipple "/path/to/large/image.jpg"))
>
> ;; Evaluate this once
> (scroll-down -3)
>
> ;; Evaluate this 3 times
> (scroll-down 1)
>
> ;; Notice that the top 3 lines now are repeated using the top portion
> ;; of the image.
>
> ;; Now evaluate these
> (scroll-down -3)
>
> (scroll-down 3)
>
> ;; Notice that the top 3 lines are now correct.
I cannot reproduce this. In fact, evaluating the first sexp has no
effect here. Perhaps stipple using an image is not supported on
MS-Windows?
Can someone else please reproduce this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Fri, 23 Mar 2012 19:05:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 11070 <at> debbugs.gnu.org (full text, mbox):
> I cannot reproduce this. In fact, evaluating the first sexp has no
> effect here. Perhaps stipple using an image is not supported on
> MS-Windows?
I don't believe stippling has ever been supported on MS Windows. But I could be
wrong.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Fri, 23 Mar 2012 23:59:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 11070 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> ;; Evaluate this
>> (face-remap-add-relative 'default
>> '(:stipple "/path/to/large/image.jpg"))
>
> I cannot reproduce this. In fact, evaluating the first sexp has no
> effect here. Perhaps stipple using an image is not supported on
> MS-Windows?
>
> Can someone else please reproduce this?
Yes, on GNU/Linux using etc/images/gnus/gnus.xbm.
There I also found this problem:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11080
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Sat, 24 Mar 2012 00:05:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 11070 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
>> (face-remap-add-relative 'default
>> '(:stipple "/path/to/large/image.jpg"))
[...]
> I cannot reproduce this. In fact, evaluating the first sexp has no
> effect here. Perhaps stipple using an image is not supported on
> MS-Windows?
No effect on GNU/Linux either, just an error message:
Invalid or undefined bitmap `/path/to/b-rock-grey.jpg' [3 times]
Are arbitrary image formats such as jpgs supported for the stipple
attribute? If I do:
(face-remap-add-relative 'default
'(:stipple "/usr/include/X11/bitmaps/xsnow"))
then something happens.
"Face Attributes" in the lispref says:
`:stipple'
The background stipple, a bitmap.
The value can be a string; that should be the name of a file
containing external-format X bitmap data. The file is found in
the directories listed in the variable `x-bitmap-file-path'.
Maybe the Nextstep port "supports" other stipple types...
Severity set to 'minor' from 'normal'
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Sat, 24 Mar 2012 00:07:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Thu, 26 Sep 2019 17:31:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 11070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Glenn Morris <rgm <at> gnu.org> writes:
> Are arbitrary image formats such as jpgs supported for the stipple
> attribute? If I do:
>
> (face-remap-add-relative 'default
> '(:stipple "/usr/include/X11/bitmaps/xsnow"))
>
> then something happens.
Oh, wow, something indeed did happen.
If somebody wants to play with this that doesn't have that file
installed, I've attached it to this message.
You get the background of the current buffer filled with snowflakes, and
when you scroll the buffer, things get very messy and ugly indeed, so I
think the bug is still present.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[xsnow (application/octet-stream, attachment)]
Added tag(s) confirmed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 26 Sep 2019 17:31:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Sat, 28 Sep 2019 09:56:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 11070 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Ivan Andrus <darthandrus <at> gmail.com>,
> 11070 <at> debbugs.gnu.org
> Date: Thu, 26 Sep 2019 19:30:32 +0200
>
> Oh, wow, something indeed did happen.
>
> If somebody wants to play with this that doesn't have that file
> installed, I've attached it to this message.
>
> You get the background of the current buffer filled with snowflakes, and
> when you scroll the buffer, things get very messy and ugly indeed
How messy and how ugly? Can you tell more? (I have no access to a
system where this feature is supported.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Sat, 28 Sep 2019 19:54:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 11070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> How messy and how ugly? Can you tell more? (I have no access to a
> system where this feature is supported.)
Here's a small buffer before eval-ing the stipple form:
[stipple1.png (image/png, inline)]
[Message part 3 (text/plain, inline)]
Then afterwards; everything looks, er nice:
[stipple2.png (image/png, inline)]
[Message part 5 (text/plain, inline)]
Then I scrolled down and up, and you can see some glitches at the top:
[stipple3.png (image/png, inline)]
[Message part 7 (text/plain, inline)]
And then I scrolled around some more and the glitches start to accumulate:
[stipple4.png (image/png, inline)]
[Message part 9 (text/plain, inline)]
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Sun, 29 Sep 2019 06:04:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 11070 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: darthandrus <at> gmail.com, rgm <at> gnu.org, 11070 <at> debbugs.gnu.org
> Date: Sat, 28 Sep 2019 21:53:22 +0200
>
> Then I scrolled down and up, and you can see some glitches at the top:
>
> And then I scrolled around some more and the glitches start to accumulate:
Do those glitches disappear if, after scrolling, you type "M-x
redraw-display RET"?
Also, could you (or someone else) try the same in some old version of
Emacs, say, 24.3?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Sun, 29 Sep 2019 11:12:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 11070 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Do those glitches disappear if, after scrolling, you type "M-x
> redraw-display RET"?
Yes, M-x redraw-display fixes the glitches.
> Also, could you (or someone else) try the same in some old version of
> Emacs, say, 24.3?
The oldest Emacs I have here is 24.5, and the glitches are present
there, too.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Sun, 29 Sep 2019 11:41:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 11070 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: darthandrus <at> gmail.com, rgm <at> gnu.org, 11070 <at> debbugs.gnu.org
> Date: Sun, 29 Sep 2019 13:11:48 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Do those glitches disappear if, after scrolling, you type "M-x
> > redraw-display RET"?
>
> Yes, M-x redraw-display fixes the glitches.
Then some redisplay optimization is at work here. If your build was
configured with --enable-checking=glyphs, does the problem go away if
you set _all_ of the following variable non-nil?
inhibit-try-cursor-movement
inhibit-try-window-id
inhibit-try-window-reusing
> > Also, could you (or someone else) try the same in some old version of
> > Emacs, say, 24.3?
>
> The oldest Emacs I have here is 24.5, and the glitches are present
> there, too.
24.5 was after Stefan removed many redisplay triggers, AFAIR, so
that's too recent. Does anyone have an older version on X and can
test that? Emacs 23 should also be good.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Sun, 29 Sep 2019 18:35:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 11070 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Then some redisplay optimization is at work here. If your build was
> configured with --enable-checking=glyphs, does the problem go away if
> you set _all_ of the following variable non-nil?
>
> inhibit-try-cursor-movement
> inhibit-try-window-id
> inhibit-try-window-reusing
No, that doesn't change anything.
But I now see more clearly what's not being updated -- it copies all the
bits in the background on the line that's being moved.
Here's the display first:
[stip1.jpg (image/jpeg, inline)]
[Message part 3 (text/plain, inline)]
Then I hit RET before the first line. The entire line moves down,
background stipples and all:
[stip2.jpg (image/jpeg, inline)]
[Message part 5 (text/plain, inline)]
And again:
[stip3.jpg (image/jpeg, inline)]
[Message part 7 (text/plain, inline)]
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Sun, 29 Sep 2019 19:27:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 11070 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: darthandrus <at> gmail.com, rgm <at> gnu.org, 11070 <at> debbugs.gnu.org
> Date: Sun, 29 Sep 2019 20:33:54 +0200
>
> > Then some redisplay optimization is at work here. If your build was
> > configured with --enable-checking=glyphs, does the problem go away if
> > you set _all_ of the following variable non-nil?
> >
> > inhibit-try-cursor-movement
> > inhibit-try-window-id
> > inhibit-try-window-reusing
>
> No, that doesn't change anything.
What about just typing "M-x" -- does that fix the display?
> But I now see more clearly what's not being updated -- it copies all the
> bits in the background on the line that's being moved.
Yes, that was clear from your original images.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Sun, 29 Sep 2019 19:30:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 11070 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> What about just typing "M-x" -- does that fix the display?
No, that doesn't seem to do anything.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#11070
; Package
emacs
.
(Mon, 30 Sep 2019 05:59:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 11070 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: darthandrus <at> gmail.com, rgm <at> gnu.org, 11070 <at> debbugs.gnu.org
> Date: Sun, 29 Sep 2019 21:29:29 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > What about just typing "M-x" -- does that fix the display?
>
> No, that doesn't seem to do anything.
OK, so the problem is deeper than redisplay optimizations.
Thanks.
This bug report was last modified 5 years and 257 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.