bug#10736: Add "underwave" face attribute

[Aurélien Aptel]

On Fri, Apr 13, 2012 at 2:49 AM, Alp Aker <alptekin.aker@gmail.com> wrote:
> Looking afresh at the small bit I contributed for ns_draw_underwave,
> it seems to me that that function does some unnecessary work with
> clipping rectangles, so I'd like to offer a slightly simpler version
> (revised patch file attached).

I agree. Most of this is necessary on X11 because the current clipping
region cannot be retrieved. If I just override it for underwaving,
non-visible text can be underwaved. My solution was to compute the
current clipping region again via get_glyph_string_clip_rect() (which
can be empty if the string is not visible) and intersect it with the
wave clipping region. Then draw the wave and set the glyph string
clipping region again.

> (In explanation of this change:  If I understand the NS port's drawing
> routine correctly, at the time this function is called the current
> clipping path has already been restricted to the glyph string's clip
> rects.  Since NSRectClip can only further restrict the current
> clipping path, there's no need explicitly to invoke the glyph string's

This is correct.

> clip rects at this point.  Indeed, I suspect the NS version could get
> away without worrying about clipping at all here, but I'm not as
> certain of this latter point.)

The underwave is computed from the left margin (every wave starts at
x=0) so that two consecutive underwaved strings appear to be
underwaved by one wave.

At first I did not use the clipping region and computed each time the
next line to draw; but for very small lines (1-2 px) the X11 drawline
primitive doesn't work well. Specifically, unneeded pixels were drawn
at both ends of the wave therefore making the juncture between two
waves visible.

My solution was to clip the region and draw a wavelet before/after when needed.

Concerning the NS port, as I understand drawing primitives work on a
non-discrete plane where integer coordinates falls "between" pixels
resulting in two blurred pixels instead of a filled one. Since I can't
experiment on this platform I was wondering if you could try shifting
every coordinate by .5 to see if it looks better.