two-pixel trace left when move overlay

two-pixel trace left when move overlay

[Drew Adams]

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

I have an overlay in buffer *Completions* to highlight the current candidate
during cycling of candidates in the minibuffer. I use this code to
reposition the overlay:

(if (symbol-value overlay)
      (move-overlay (symbol-value overlay) start end buffer)
    (set overlay (make-overlay start end buffer))
    (overlay-put (symbol-value overlay) 'face face))

In Emacs 20, 21, and a CVS snapshot of June 26, 2005, this works OK. In a
CVS snapshot of 2006-03-20, when I move the overlay, a two-pixel (I believe)
trace is left behind. See attached screenshots.

[-- Attachment #2: bug-emacs-22-Completions-pixel.jpg --]
[-- Type: image/jpeg, Size: 198824 bytes --]

[-- Attachment #3: bug-emacs-22-Completions-pixel-closeup.jpg --]
[-- Type: image/jpeg, Size: 67082 bytes --]

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: two-pixel trace left when move overlay

[Kim F. Storm]

"Drew Adams" <drew.adams@oracle.com> writes:

> I have an overlay in buffer *Completions* to highlight the current candidate
> during cycling of candidates in the minibuffer. I use this code to
> reposition the overlay:
>
> (if (symbol-value overlay)
>       (move-overlay (symbol-value overlay) start end buffer)
>     (set overlay (make-overlay start end buffer))
>     (overlay-put (symbol-value overlay) 'face face))
>
> In Emacs 20, 21, and a CVS snapshot of June 26, 2005, this works OK. In a
> CVS snapshot of 2006-03-20, when I move the overlay, a two-pixel (I believe)
> trace is left behind. See attached screenshots.

Hi Drew,  I tried to reproduce this with the files you sent me (I had to get
hexrgb.el from the wiki), but I don't see the problem on X/GNU/Linux.

Perhaps it is a Windoze specific problem?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

RE: two-pixel trace left when move overlay

[Drew Adams]

    > I have an overlay in buffer *Completions* to highlight the
    > current candidate
    > during cycling of candidates in the minibuffer. I use this code to
    > reposition the overlay:
    >
    > (if (symbol-value overlay)
    >       (move-overlay (symbol-value overlay) start end buffer)
    >     (set overlay (make-overlay start end buffer))
    >     (overlay-put (symbol-value overlay) 'face face))
    >
    > In Emacs 20, 21, and a CVS snapshot of June 26, 2005, this
    > works OK. In a
    > CVS snapshot of 2006-03-20, when I move the overlay, a
    > two-pixel (I believe)
    > trace is left behind. See attached screenshots.

    Hi Drew,  I tried to reproduce this with the files you sent me
    (I had to get
    hexrgb.el from the wiki), but I don't see the problem on X/GNU/Linux.

    Perhaps it is a Windoze specific problem?

No doubt (since I see it systematically, with just those files). Thanks for
trying on X/GNU/Linux.

Re: two-pixel trace left when move overlay

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Mon, 24 Apr 2006 00:49:49 +0200
> Cc: Emacs-Devel <emacs-devel@gnu.org>
> 
> "Drew Adams" <drew.adams@oracle.com> writes:
> 
> > I have an overlay in buffer *Completions* to highlight the current candidate
> > during cycling of candidates in the minibuffer. I use this code to
> > reposition the overlay:
> >
> > (if (symbol-value overlay)
> >       (move-overlay (symbol-value overlay) start end buffer)
> >     (set overlay (make-overlay start end buffer))
> >     (overlay-put (symbol-value overlay) 'face face))
> >
> > In Emacs 20, 21, and a CVS snapshot of June 26, 2005, this works OK. In a
> > CVS snapshot of 2006-03-20, when I move the overlay, a two-pixel (I believe)
> > trace is left behind. See attached screenshots.
> 
> Hi Drew,  I tried to reproduce this with the files you sent me (I had to get
> hexrgb.el from the wiki), but I don't see the problem on X/GNU/Linux.
> 
> Perhaps it is a Windoze specific problem?

If someone gives a precise recipe, starting with "emacs -Q", to
reproduce this, I could see if today's CVS exhibits the problem on
Windows.

Re: two-pixel trace left when move overlay

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 2078 bytes --]

Kim F. Storm wrote:
> "Drew Adams" <drew.adams@oracle.com> writes:
>
>   
>> I have an overlay in buffer *Completions* to highlight the current candidate
>> during cycling of candidates in the minibuffer. I use this code to
>> reposition the overlay:
>>
>> (if (symbol-value overlay)
>>       (move-overlay (symbol-value overlay) start end buffer)
>>     (set overlay (make-overlay start end buffer))
>>     (overlay-put (symbol-value overlay) 'face face))
>>
>> In Emacs 20, 21, and a CVS snapshot of June 26, 2005, this works OK. In a
>> CVS snapshot of 2006-03-20, when I move the overlay, a two-pixel (I believe)
>> trace is left behind. See attached screenshots.
>>     
>
> Hi Drew,  I tried to reproduce this with the files you sent me (I had to get
> hexrgb.el from the wiki), but I don't see the problem on X/GNU/Linux.
>
> Perhaps it is a Windoze specific problem?
>
>
>   
It is almost certainly due to this change:

2005-07-01  Jason Rumney  <jasonr@gnu.org>

    * w32term.c (cleartype_active): New flag for enabling sub-pixel
    workaround.
    (w32_initialize): Initialize it.
    (w32_native_per_char_metric): Allow a couple of extra pixels when
    Cleartype is active.

    * w32term.c (w32_initialize): Move check for screen reader here
    from syms_of_w32term.

The history of this is:

In Windows XP, "Cleartype" sub-pixel anti-aliasing was introduced. With 
some fonts, this caused a garbaged display, since characters draw 
outside of their advertised bounding box.

In 21.3 I disabled the use of Cleartype in Emacs to avoid this problem, 
but users complained, so a workaround of increasing the width of the 
bounding box by one pixel left and right was installed. This should 
cause Emacs to always draw a whole line at a time (after figuring out 
that characters on that line are overlapping), which is the advice that 
Microsoft gives to avoid this problem.

I guess the workaround must be adversely affecting the drawing of 
overlays though - the extra two pixels being drawn on the background, 
but not detected when it comes time to erase them.


[-- Attachment #1.2: Type: text/html, Size: 2779 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

RE: two-pixel trace left when move overlay

[Drew Adams]

      In Emacs 20, 21, and a CVS snapshot of June 26, 2005, this works OK.
In a
      CVS snapshot of 2006-03-20, when I move the overlay, a two-pixel (I
believe)
      trace is left behind. See attached screenshots.

    Perhaps it is a Windoze specific problem?

  It is almost certainly due to this change:

  2005-07-01  Jason Rumney  <jasonr@gnu.org>

    * w32term.c (cleartype_active): New flag for enabling sub-pixel
    workaround.
    (w32_initialize): Initialize it.
    (w32_native_per_char_metric): Allow a couple of extra pixels when
    Cleartype is active.

    * w32term.c (w32_initialize): Move check for screen reader here
    from syms_of_w32term.

  The history of this is:

  In Windows XP, "Cleartype" sub-pixel anti-aliasing was introduced. With
some fonts,
  this caused a garbaged display, since characters draw outside of their
advertised
  bounding box.

  In 21.3 I disabled the use of Cleartype in Emacs to avoid this problem,
but users
  complained, so a workaround of increasing the width of the bounding box by
one pixel
  left and right was installed. This should cause Emacs to always draw a
whole line at
  a time (after figuring out that characters on that line are overlapping),
which is
  the advice that Microsoft gives to avoid this problem.

  I guess the workaround must be adversely affecting the drawing of overlays
though -
  the extra two pixels being drawn on the background, but not detected when
it comes
  time to erase them.

Here's another piece of the puzzle (mentioned in my initial bug report): The
bug only appears if (setq-default indent-tabs-mode nil). If this is non-nil
there is no problem.