Re: Unifying code for drawing on a cairo context

[Po Lu]

"Pfrommer, Julius" <julius.pfrommer@web.de> writes:

> The X and the PGTK toolkits both support a cairo "glass". Their code for
> drawing on a cairo context is virtually identical. Yet the
> implementations have started to diverge.
>
> As an example, x_draw_horizontal_wave and pgtk_draw_horizontal_wave are
> virtually the same. But the X implementation takes a "GC" graphics
> context, whereas the PGTK implementation now takes a "color" integer
> argument.
>
> https://git.savannah.gnu.org/cgit/emacs.git/tree/src/xterm.c#n5155
> https://git.savannah.gnu.org/cgit/emacs.git/tree/src/pgtkterm.c#n1995
>
> Obviously maintaining duplicate code is an anti-pattern. I'd like to
> pull out common cairo functionality bit-by-bit into methods to be used
> by both the X and the PGTK toolkit.
>
> With the cairo primitives unified between X and PGTK, adding a cairo
> "glass" for more toolkits should also become easier as a future option
> (ns, haiku, w32).

They take different arguments because they operate on top of different
graphics APIs.  Graphics contexts are an important resource in the X
Windows graphics API, while GDK got rid of them in favor of specifying
colors directly.

On Haiku, Cairo is only used for fonts that have complex shaping
requirements, and it will not be used for anything else.  I don't see
what benefits Cairo drawing would bring on NS or W32 either, except for
apparently more flicker, which is so bad on Haiku that double buffering
cannot be turned off when Cairo drawing is enabled.

But at present, there is no benefit to those changes.  I'm also not
convinced we will be able to have "one-size-fits-all" Cairo code for the
different window systems that are out there: X, PGTK and Haiku already
have different methods of handling scaling, fringe bitmaps, and even
images and image transforms, and the existing Cairo code in both
terminals (and fringe.c, and some other place that I can't find right
now) is certainly not general enough to apply to every system out there.

There is nothing troublesome about maintaining the Cairo code as it is.

I would rather wait for that to become an actual problem (by my
judgement, or the judgement some other person who is actually working on
the relevant code) before trying to put all the code together.

Thanks.

To answer your other questions:

> But I'm unsure about how this fits with ongoing development and which
> conventions to follow.
>
> - Would the unified cairo function be called cairo_draw_horizontal_wave,
> establishing a new cairo_ prefix convention?

No, it should be shorter, something like `cr_draw_horizontal_wave'.

> - Should such functions generally take an immediate cairo_t context as
> input or some "larger" struct that includes that cairo_t and can be
> extended in the future (e.g. with foreground and background color
> information).

It would ideally take an Emacs_GC and a cairo context, and use the
foreground color of that GC, except on the window systems where there is
no concept of a GC (namely Haiku), in which case it should take the
system native color type (unsigned long on Haiku.)

> - Is it okay to create the files cairoterm.h/.c or can we expect
> functionality beyond "term" to be added over time as well?

Just call it 'crfns.c', which describes its functionality much better,
since it doesn't read input or write to a terminal.