Merge parts of CairoCFFI into PyCairo

[stuaxo]

This is a bit speculative... and I'm not going to have time to do anything for a while, but thought I'd write this here in the meantime -

CFFI vs CPython bindings background

CFFI has an advantage, in that code runs in pypy more permanently, and had better chance of working on alternate implementations.

CPython bindings such as pycairo have other advantages, like the C-API.

History of PyCairo vs CairoCFFI

PyCairo was not supported for a long time, and also could not work on Pypy because it is based on Pythons CAPI.

CairoCFFI was built on the CFFI bindings, to run (performantly) on Pypy.

In the meantime PyCairo was unsupported for so long that CairoCFFI started to support newer Cairo features such as Recording Surfaces.

However some features were hard to get into CairoCFFI without support from PyCairo, around Gtk integration

At that point there were two choices for a developer -

• Use PyCairo, and only have support for Cairo features up to 1.10, have good integration with Gtk, but not Pypy support.
• Use CairoCFFI and enjoy Pypy support, but have trouble later on when it comes to Gtk and (it will be different to PyCairo at the very least).

Current status

@lazka has triaged patches and released an up to date PyCairo, the project is healthy... lots of historical things sorted, like installation.

PyCairo is probably ahead of CairoCFFI when it comes to features, but still - CairoCFFI works better under Pypy.

What are analogous projects doing ?

• Pypy
  originally was going to reimplement Numpy, with Numpypy. Now, Pypy has changed strategy and are going to try and implement enough on the low level for numpy to just work.

• Servo
  Is a proof of concept web browser written in Rust. Instead of replacing the Firefox with servo, they are taking parts Servo and integating them into firefox.

Looking ahead

Having two projects it's inevitable that one will fall ahead while the other lags.
Further into the future it might be an idea to follow the lead of firefox and servo and try and integrate bits of CairoCFFI into PyCairo.

There are things that can't be done in CFFI, like the Cairo CAPI - but these could just not be supported - the possibly the bindings part of PyCairo could be done in CFFI, like it is in CairoCFFI (I believe the code should be license compatible).

Apologies if any of this is incorrect, some of it I'm recalling from mailing list conversations quite a while ago.

Not expecting anything to happens on this, and not going to have any time for quite a while, but it would be good to get some feedback.

[lazka]

As long as the module import performance isn't too much affected, I'm OK with everything which makes pypy users happy and I'll try to help if possible. But I won't be looking into any of this.

[stuaxo]

Mostly this is a note to myself in the future, since I won't have time for a while.

I'm happy to move it off the bug tracker - though I guess there is an infinitesimally small chance of another dev seeing it and picking it up.

When there is a time, I was thinking about starting a fork and trying this with something like ImageSurface first.

[lazka]

I don't mind leaving this here.

Another approach would be to improve cairocffi instead (since much of this is needed anyway for a potential merger imo)

• Implementing the pycairo C-API might be possible (see Pycairo C API support Kozea/cairocffi#18)
• Move to the out-of-line API for better import performance: https://cffi.readthedocs.io/en/latest/overview.html#real-example-api-level-out-of-line
• Implement the newly added APIs present in pycairo

I thought about doing this myself before looking into pycairo, but improving pycairo seemed like it would help more projects in the short term.

[stuaxo]

Definitely agree that improving pycairo was the way with the most benefit, it's made a big difference :)

This all makes a lot of sense, I didn't know about the out-of-line API.

Just to check my understanding of the C-API -

• This is used by PyGobject to so that Gtk + PyCairo to interface with each other.
• CairoCFFI does not currently support it (?)
• It would be useful for CairoCFFI to support it because to allow mixing PyGobject (Gtk)... which is mostly desirable (in the longer term PGI would be a good solution, but getting full compatibility, e.g. inheritance, interfaces etc would be quite a bit of work).

[lazka]

This is used by PyGobject to so that Gtk + PyCairo to interface with each other.

yes

CairoCFFI does not currently support it (?)

yes

It would be useful for CairoCFFI to support it because to allow mixing PyGobject (Gtk)... which is mostly desirable [..]

I don't know of any benefits cairocffi has over pycairo for PyGObject, so probably not. Maybe if someone gets PyGObject working under PyPy...

[stuaxo]

I'm going to close this now, PyPy has got to the point where PyGobject works well enough. CFFI is still a great choice for building a brand new API, but there is a lot of work here using the python C API.

What could be interesting in the future is moving to HPy, since it aims to be similar to the CPython C API, but have good performance in PyPy and be compatible with other python implementations -

https://morepypy.blogspot.com/2019/12/hpy-kick-off-sprint-report.html