bug#35468: [PATCH] Refactor draw_glyph_string on X and w32

[mituharu@math.s.chiba-u.ac.jp]

> mituharu@math.s.chiba-u.ac.jp writes:
>
>> Unlike the NS port, the terminal code in the Mac port is much like the
>> X11
>> version.
>
> I looked at your code and fortunately it indeed looks like the same
> abstractions for glyph drawing that would work for the X11 version would
> work for the Mac port.

I deliberately made the Mac port code aligned to the X11 version
for the consistency in behavior as well as the ease of catching
up upstream changes.

> Why does it use the background color of GC? It appears that the
> Cairo version uses the foreground color of GC; is that because the Cairo
> version doesn't handle stippling?

I wrote both Mac and cairo versions, and I used the foreground
color for cairo (although I already used the background color on
the Mac port) to minimize the changes from the Xlib version
because it was incorporated into xterm.c.

Actually the stipple bitmap support for the Mac port was added
very recently.  It had been missing in the Mac port for more than
a decade because I also thought it is an outdated thing and not
worth implemented.  But I changed my mind by looking at an
unexpected use of stipple bitmaps:

  https://lists.gnu.org/r/emacs-devel/2019-03/msg00502.html

So the use of the background color of GC on the Mac port is not
for stipple bitmaps (at least historically) but mainly for the
following reasons:

  1. It can avoid XGetGCValues dance you mentioned without the
     drastic changes in the code that may make catching up
     mainstream difficult.
  2. There are multiple cases that "filling with the background
     color" is useful.
  3. The Mac port supports "vibrancy" (a frosted-glass-like
     translucency effect) only for the background color.  So
     filling with the background color is implemented differently
     from doing that with the foreground color on the Mac
     port (see the macro CG_CONTEXT_FILL_RECT_WITH_GC_BACKGROUND
     in macterm.h).  It is regarded as "special stipples" and
     actually controlled by the stipple attibute of faces:
     https://bitbucket.org/mituharu/emacs-mac/src/df827786d7a7fb0a0e2f27577af67e32d9a888a9/doc/emacs/macport.texi#lines-519
     In retrospect, it is natural to associate "stipple"
     operations with "erasing" (filling with the background
     color) in this sense.

>> I guess introducing the erase_rectagle handler makes things simpler and
>> efficient.
>
> Looking over the code, and considering that stippling is quite uncommon
> nowadays (GTK 3 removed it, AFAIK), I think the best approach would be
> to define 3 separate interface procedures:
>
> 1) fill_rectangle: handles x_fill_rectangle/mac_fill_rectangle
>
> 2) fill_rectangle_with_color: handles (1), but also with the temporary
> overriding of the GC that's done frequently for mac_erase_rectangle.
>
> 3) fill_rectangle_with_stipple: handles the temporary XFillStyle
> overriding of the GC.
>
> A third procedure wouldn't be inelegant in comparison to the
> alternatives, since otherwise I would need a set_context_stipple
> procedure to indicate stippling.
>
> Then mac_fill_rectangle can be assigned to fill_rectangle, and
> mac_erase_rectangle can be assigned to fill_rectangle_with_stipple.

Because of the reasons I mentioned above, I'd prefer
erase_rectangle to fill_rectangle_with_color/stipple.  Also, many
use cases in the Mac port involve erasure of multiple rectangles,
so erase_rectangles (multi-rectangle version like
XFillRectangles) would eliminate some overhead of setting up
colors and the clipping area.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp