scope: cairo

[ssj71]

Let's discuss cairo.

Its been proposed cairo not be an interface of pugl, but instead a separate project or easy recipe provide devs with that interface.

Does using cairo on top of the openGL libraries reduce performance? Is it significant?

Is the added API complexity of providing the cairo interface high enough to warrant removal? Is backend complexity significant?

Other considerations?

[jpcima]

I'm the initial contributor of cairo in DPF.

Other considerations?

Yes, and no small one as I'm concerned, compatibility.

I would say I adopt cairo not particularly by its own virtue, but rather by avoidance of openGL. openGL has a compatibility problem with old machines, which manifests itself in plugins, including simple ones which are 2d drawn.

There were quite a few reports around Librazik OS, that numerous openGL plugins don't draw such or such element right, or even don't draw at all. (including the ubiquitous zyn-fusion) The suggested software GL workaround is not beginner-friendly, and computationally inefficient.

First time users will usually have their first contact with Linux on an old spare machine, and because of lacking openGL it can turn as a bad first experience, despite a machine which will be overwise apt at musical processing.

• about cairo in pugl

On the minus side, cairo is an added external dependency, and GL is the quick and present everywhere path to portability. I understand it, but imho openGL portability is an illusion.

It has been alluded that pugl should be an abstraction of the same kind as Gdk. I agree. Note that Gdk also includes a drawing abstraction, which it provides through cairo.

• On having cairo inside, or outside pugl:

Cairo will be most likely tied to the low-level window drawing system. By itself, it already provides the drawing ability on top of Mac Quartz or Windows Gdi surfaces. This drawing will be intricately tied to some constraits of the OS operation.

For instance, X11 enables a life-long drawing context which is valid at all times, whereas Windows has a cycle-long validity which is bound to the WM_PAINT callback. It's a reason why it's good that pugl controls cairo, and can drive the graphics invocation at the appropriate point in time.

API complexity

Nothing much really. In DPF, I believe the API has been minimalized; the use of cairo has been turned into a compile-time choice rather than a run-time one.

Is backend complexity significant?

It certainly adds a decent bit, yes. It's possible to observe the conditional regions and judge yourself.

[ssj71]

@jpcima thanks for your thoughts. Just to clarify for myself, would the OpenGL portability quirks that you mention also pop up if we use the OpenGL backend of cairo rather than the native X11/Quartz/Gdi backends?

[jpcima]

I've never tried. However, if we have some test cases at hand, we can ask @trebmuh who is a "lucky" owner of a machine which a highly disfunctional openGL configuration for audio software.

[trebmuh]

That much of a luck :wink:

[drobilla]

Cairo was added become some people wanted it, and it's dramatically more friendly for simple 2D things.

Regardless, I factored out the drawing backend from the window system implementation (f46b512), which is a much better design anyway, so if you don't want Cairo in pugl, just don't copy those files. This is currently only implemented this way for X11 though.

As it happens, this also means people can implement native, or RGB, or Vulkan, or whatever other contexts they feel like adding.

Is backend complexity significant?

The backend complexity is now 3 lines of code. It doesn't seem worth the effort to make it 0, but that could probably be done by making the application code have to deal with it.

[drobilla]

It doesn't seem worth the effort to make it 0, but that could probably be done by making the application code have to deal with it.

This was gnawing at me, so I just did it. Pugl's "core" now has no dependencies on either GL or Cairo, backends are completely separate. This required yet more minor API breakage (sorry, stability soon...), but so it goes.

I also added Cairo Mac and Windows backends and made sure all three are working decently (for me, anyway). Here is the Mac one for example: https://github.com/drobilla/pugl/blob/master/pugl/detail/mac_cairo.m

FWIW it seems to me that Cairo on Quartz works really well. It's definitely no match for GL on any platform at doing full-blast animation, but if you can swallow the dependency it's a pretty sensible choice for just drawing some widgets. Particularly if you care about Apple, since Quartz is pretty much guaranteed to work well and be actively maintained there forever. Cairo-on-GL-on-Mac is silly.

Funnily enough, it seems like X11 is the worst platform for it. I couldn't figure out vsync or get Cairo to play nice with Xdbe, so it's a bit janky if you're doing things like resizing during animation, but it's good enough. Everything is dramatically better than the old upstream, anyway, which was pretty crap.

[ssj71]

awesome. I just wanted a cairo backend anyway. I started all this when I realized that it was only working in X11 and some forks had implemented cairo on the other platforms. Thanks for doing the work AND for commenting on your motivations here.