"Bold" effect when anti-aliased glyphs are overwritten

"Bold" effect when anti-aliased glyphs are overwritten

[Chong Yidong]

I've been noticing that glyphs near the cursor occasionally become
"bold" for no reason.  Here's a way to reproduce it:

(defun glyph-test ()
  (interactive)
  (switch-to-buffer "*Test*")
  (erase-buffer)
  (insert "\n ABC")
  (goto-char (point-min)))

M-x glyph-test RET
[down]

The first glyph on the second line, displaying the character "A", now
becomes a little bolder.  Now do

[up]
[down]

Each time, the "A" gets bolder and bolder.

This might depend on the exact font you use (mine is Mono-10).

The reason this happens is that when the redisplay engine calls
draw_glyphs to draw certain glyphs, such as the cursor glyph,
neighboring glyphs are redrawn if there is a left or right overhang
(xdisp.c:19929).

Currently, the foreground of these redrawn glyphs is drawn directly
without erasing the existing glyph.  This is because we generally don't
want to redraw the background, since that might in turn overwrite THIS
glyph's neighbors.  Without anti-aliasing, this procedure is obviously
unproblematic.

With anti-aliasing, it doesn't work well.  Apparently, during the
anti-aliasing calculation, the entire existing glyph---including the
glyph foreground---is treated as the "background".  Thus, the
anti-aliased parts of the foreground character becomes more and more
prominent, and eventually saturates completely.

Does anyone have any ideas for fixing this?

Re: "Bold" effect when anti-aliased glyphs are overwritten

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> I've been noticing that glyphs near the cursor occasionally become
> "bold" for no reason.
>
> The reason this happens is that when the redisplay engine calls
> draw_glyphs to draw certain glyphs, such as the cursor glyph,
> neighboring glyphs are redrawn if there is a left or right overhang
> (xdisp.c:19929).
>
> With anti-aliasing, it doesn't work well.  Apparently, during the
> anti-aliasing calculation, the entire existing glyph---including the
> glyph foreground---is treated as the "background".  Thus, the
> anti-aliased parts of the foreground character becomes more and more
> prominent, and eventually saturates completely.

I've checked in a fix into CVS.  Please let me know if it causes any
problems.

Re: "Bold" effect when anti-aliased glyphs are overwritten

[Stephen Berman]

On Tue, 27 May 2008 17:09:29 -0400 Chong Yidong <cyd@stupidchicken.com> wrote:

> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> I've been noticing that glyphs near the cursor occasionally become
>> "bold" for no reason.
>>
>> The reason this happens is that when the redisplay engine calls
>> draw_glyphs to draw certain glyphs, such as the cursor glyph,
>> neighboring glyphs are redrawn if there is a left or right overhang
>> (xdisp.c:19929).
>>
>> With anti-aliasing, it doesn't work well.  Apparently, during the
>> anti-aliasing calculation, the entire existing glyph---including the
>> glyph foreground---is treated as the "background".  Thus, the
>> anti-aliased parts of the foreground character becomes more and more
>> prominent, and eventually saturates completely.
>
> I've checked in a fix into CVS.  Please let me know if it causes any
> problems.

It fixes the cases I have encountered.  Thanks!

Steve Berman

Re: "Bold" effect when anti-aliased glyphs are overwritten

[Jason Rumney]

Chong Yidong wrote:
> Currently, the foreground of these redrawn glyphs is drawn directly
> without erasing the existing glyph.  This is because we generally don't
> want to redraw the background, since that might in turn overwrite THIS
> glyph's neighbors.  Without anti-aliasing, this procedure is obviously
> unproblematic.
>   
The usual way to solve such problems is to use clipping to only erase 
and draw the parts of the neighboring glyphs that need redrawing.
I thought I had seen such code when porting the new font backend to 
Windows, but perhaps I am misremembering.

Re: "Bold" effect when anti-aliased glyphs are overwritten

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

> The usual way to solve such problems is to use clipping to only erase
> and draw the parts of the neighboring glyphs that need redrawing.
> I thought I had seen such code when porting the new font backend to
> Windows, but perhaps I am misremembering.

Yeah, it turned out to be a bug in x_draw_glyph_string; the clipping
mask was not being used.  I've changed xterm.c; could you take a look at
w32term.c and see if it also needs fixing?

Re: "Bold" effect when anti-aliased glyphs are overwritten

[Kenichi Handa]

In article <87zlqbxx2t.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> Yeah, it turned out to be a bug in x_draw_glyph_string; the clipping
> mask was not being used.  I've changed xterm.c; could you take a look at
> w32term.c and see if it also needs fixing?

Thank you for fixing it!

---
Kenichi Handa
handa@ni.aist.go.jp

Re: "Bold" effect when anti-aliased glyphs are overwritten

[Kenichi Handa]

In article <87ve0zmy8p.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:

> I've been noticing that glyphs near the cursor occasionally become
> "bold" for no reason.  Here's a way to reproduce it:

I've noticed it too.  I think the problem is because Xft
font-backend fails to redraw background before drawing
characters for anti-aliased font.  But, I have not yet found
why that happens.

---
Kenichi Handa
handa@ni.aist.go.jp