[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: two-pixel trace left when move overlay

From: Jason Rumney
Subject: Re: two-pixel trace left when move overlay
Date: Mon, 24 Apr 2006 11:45:18 +0100
User-agent: Thunderbird (Windows/20060308)

Kim F. Storm wrote:
"Drew Adams" <address@hidden> 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  <address@hidden>

    * w32term.c (cleartype_active): New flag for enabling sub-pixel
    (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]