Perhaps it makes sense to prefer pycairo now? (as pygobject will go through pycairo regardless).
In fact, does pygobject even work (in this use case) without pycairo?

I saw that there is code to convert pycairo objects to cairocffi ones for some fastpath implementations, so I assumed it is still preferred.

If there is anything I can do in pycairo to make it the preferred one I'm happy to help.

In fact, does pygobject even work (in this use case) without pycairo?

No, it can be build without pycairo but then any function using cairo types will not work.

Which means in particular on_draw_event (connected to the "draw" event), no?
IOW, can we just assume that gtk3 is built with cairo support and that cairo is a dependency, and error out early if not?

I don't think keeping the cairocffi optional dependency just for the sake of a not-even-twofold speedup is worth it (but if you want to make expose something similar in pycairo's side what would be needed is a way to create a cairo Path from a list of cairo_path_data_t (or better, from a buffer (in the memoryview sense), so that no copy at all is done). (Effectively, this runs afoul of the last paragraph ofhttps://cairographics.org/manual/bindings-path.html ("You should not present an API for mutating or for creating new cairo_path_t objects. In the future, these guidelines may be extended to present an API for creating a cairo_path_t from scratch for use with cairo_append_path() but the current expectation is that cairo_append_path() will mostly be used with paths from cairo_copy_path()."), but performance wise it does make some difference.)

Which means in particular on_draw_event (connected to the "draw" event), no?

yeah

IOW, can we just assume that gtk3 is built with cairo support and that cairo is a dependency, and error out early if not?

We havehttps://pygobject.readthedocs.io/en/latest/guide/api/api.html?highlight=require_foreign#gi.require_foreign to check for this.

I don't think keeping the cairocffi optional dependency just for the sake of a not-even-twofold speedup is worth it [...]

Thanks, I'll have a look.

Either way I think any changes to the cairo part should be another PR.

It was originally done to support py3 but I guess yeah I don't know the situation with pypy right now either,@lazka?

It was originally done to support py3

Yeah, the pycairo in Ubuntu 16.04 for example (the distro provided package) is lacking various API compared to the Python 2 version, and also has a few bugs/crashers.

I don't know the situation with pypy right now either,

PyGObject and Pycairo do work with PyPy now:https://lazka.github.io/posts/2018-04_pypy-pygobject/index.html but pycairo is probably slower than cairocffi with PyPy.

xenial has pycairo 1.10 but we require 1.11 indeed.

@anntzer if I just take the code in _append_paths_fast() that computes codes/vertices and loop over them and call the path functions I get the same FPS boost as with the buffer passing approach (unless I'm missing something). So I think the whole cairo_path_data_t thing is not needed and the fast path would also works with pycairo as is.

(tested with wire3d_animation_sgskip)

ah, the "fast path" cleans up the path first, so they aren't doing the same thing.The main speedup comes from removing the curve segments. So assuming that shortcut is OK this would be faster than the current fast path for both libraries: (turned out to be wrong, see my PRs)

# Mapping from Matplotlib Path codes to cairo path functions._MPL_TO_CAIRO_PATH_TYPE= [lambdactx,*args:None]* (Path.CLOSEPOLY+1)_MPL_TO_CAIRO_PATH_TYPE[Path.MOVETO]=cairo.Context.move_to_MPL_TO_CAIRO_PATH_TYPE[Path.LINETO]=cairo.Context.line_to_MPL_TO_CAIRO_PATH_TYPE[Path.CLOSEPOLY]= \lambdactx,*args:cairo.Context.close_path(ctx)def_append_path(ctx,path,transform,clip=None):cleaned=path.cleaned(transform,remove_nans=True,clip=clip)forpoints,codeinzip(cleaned.vertices,cleaned.codes):_MPL_TO_CAIRO_PATH_TYPE[code](ctx,*points)

Is there a reason PyGObject is pinned to this specific version?

Just the latest stable release to keep the CI environment stable and in case PyGObject drops Ubuntu 16.04 support, even though there are no plans to do so right now.

I can remove it if you want.

Not quite sure on our version policy for CI. Keeping it stable and always testing the mos recent one both have their benefits. Nevertheless, I would go with the most recent.

@tacaswell Do you have an opinion on version pinning here?

I've removed the pinning now.

a belated 👍 to removing the pinning. Would rather deal with broken CI than finding out after things are released.