From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: two-pixel trace left when move overlay Date: Mon, 24 Apr 2006 11:45:18 +0100 Message-ID: <444CAC3E.4070600@gnu.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1017653366==" X-Trace: sea.gmane.org 1145875544 20642 80.91.229.2 (24 Apr 2006 10:45:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Apr 2006 10:45:44 +0000 (UTC) Cc: Drew Adams , Emacs-Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 24 12:45:43 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FXyZa-0002nK-LN for ged-emacs-devel@m.gmane.org; Mon, 24 Apr 2006 12:45:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXyZa-0006QV-43 for ged-emacs-devel@m.gmane.org; Mon, 24 Apr 2006 06:45:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FXyZM-0006QQ-QU for emacs-devel@gnu.org; Mon, 24 Apr 2006 06:45:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FXyZK-0006QE-TL for emacs-devel@gnu.org; Mon, 24 Apr 2006 06:45:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXyZK-0006QB-NY for emacs-devel@gnu.org; Mon, 24 Apr 2006 06:45:26 -0400 Original-Received: from [213.86.207.50] (helo=exchange.integrasp.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FXybW-0005Nz-OV for emacs-devel@gnu.org; Mon, 24 Apr 2006 06:47:44 -0400 Original-Received: from ASSP-nospam (localhost [127.0.0.1]) by exchange.integrasp.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JL5J49X0; Mon, 24 Apr 2006 11:38:27 +0100 Original-Received: from 192.168.111.65 ([192.168.111.65] helo=[192.168.111.65]) by ASSP-nospam ; 24 Apr 06 10:38:27 -0000 User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) Original-To: "Kim F. Storm" In-Reply-To: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:53314 Archived-At: This is a multi-part message in MIME format. --===============1017653366== Content-Type: multipart/alternative; boundary="------------080504040408090408010100" This is a multi-part message in MIME format. --------------080504040408090408010100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kim F. Storm wrote: > "Drew Adams" 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 * 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. --------------080504040408090408010100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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.

--------------080504040408090408010100-- --===============1017653366== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============1017653366==--