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  <address@hidden>

    * 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.