Re: Unifying code for drawing on a cairo context

[Pfrommer, Julius]

> I think that we won't be able to get the Cairo code all in one place,
> without a large amount of code specific to each window system, which
> defeats the point of such refactoring.

Not all Cairo drawing, but those parts where it makes sense.
But having some level of code-sharing will decrease the "entropy"
pulling the toolkits and platforms apart over time.

> The platforms where Cairo drawing is currently used already have subtle
> differences in their Cairo-related code to take care of
> platform-specific quirks regarding fringes, image transforms, scaling,
> etc.

Agreed, there are differences. But every Cairo operation eventually
translates to an API call on a cairo_t "glass". Some platforms already
have a "scaling-factor" as part of their Cairo drawing. Most of these
platform-dependent differences could be handled by a slim wrapper on top
of a common drawing implementation.

> Moving all the Cairo code in one place would impose
> a severe limitation on the ability to change the Cairo code for a single
> window system, at least without the preprocessor definition mess that
> this refactoring will hopefully avoid.

I would argue to the contrary. Developers typically only have access to
a subset of the platforms. Developers will improve and bugfix only those
platforms where they can test their changes. Having a common core for
Cairo-drawing (with no #ifdef mess and assuming that Cairo behaves
similarly across platforms) would reduce the duplication of the effort
to fix bugs.

Anyhow, instead of hypothesizing, I will try out a couple of approaches
to see how/whether the overall complexity is reduced by pulling out
common drawing operations on top of the cairo_t "glass".

Regards, Julius