Re: Unifying code for drawing on a cairo context

[Po Lu <luangruo@yahoo.com>]

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

> 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.

There will be no benefit to this at all.  We only recently introduced a
second platform where Cairo drawing is used, and aside from GTK (and X
Windows, where using Cairo for stuff other than fonts was apparently
implemented so that we could use it for printing in the future, but
nobody has shown any interest in doing that work), there are no other
platfoms where Cairo drawing is required or would be beneficial.

So IMNSHO this refactoring is premature, and will also likely cause
problems down the road when we want to change the behavior of the Cairo
code on a platform-specific basis, such as when the device scaling
feature is implemented on X.

> 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.

I work on both platforms where Cairo drawing is used for something other
than fonts and see no "ifdef mess" you allude to in the Cairo code, and
so far there hasn't been a single instance of the two instances of
subtly different Cairo code causing fixing a bug to require a
duplication of effort.  Most of the preprocessor conditionals in the X
Windows drawing code stem from the presence of both a Cairo and
non-Cairo configuration, neither of which are going away.

Cairo is not used at all on NS and MS Windows, so bug fixes will have to
be made separately there in any case.  The Haiku port will also never
use Cairo for drawing anything other than text with complex shaping
requirements.

On the other hand, why not dedicate your time to some work on the PGTK
port that will lead to an immediate improvement, such as refactoring the
selection code in `pgtkselect.c' to use the low-level GDK selection API,
so that drag-and-drop will work, and most of the Lisp-level selection
code can be shared with X?

Thanks in advance.