CairoGL support

[stuaxo]

@cubicool implemented bindings with C++ for CairoGL (and SDL) a while ago.

https://github.com/cubicool/cairo-gl-sdl2

Some distros support the GL backend and others don't, when I last checked Fedora supported, Debian / Ubuntu did not.

[stuaxo]

@Macslow's post, and link to Cairo GL Playground code (in C):

https://plus.google.com/113208190542460553234/posts/cZVh9qNqRvC

[kalev]

We've now dropped cairo-gl support in Fedora as well: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RKZMG26MKUEM2W74ILCC5RL7A2XMJRFN/

[lazka]

Thanks for the info.

@stuaxo I guess we can close this then?

[stuaxo]

I'd he keen for this to he supported, just not sure where to start - compiling with this enabled is straightforward.

I guess if I managed this it might be possible to make a pycairo-experimental with other backends such as gl enabled.

[lazka]

ok, sure

[briend]

It would be fantastic to have open-gl backend in PyCairo. I've been playing around with OpenColorIO and python and pycairo surfaces, and it seems the only good path forward would be to write images directly onto a cairo GL surface to allow OpenColorIO to configure the GPU shader to do all the color management and view transforms. Otherwise, I have to use the CPU and performance is pretty terrible.

There is more recent development of the GL backend in Cairo, so it's not quite dead. https://blogs.s-osg.org/introducing-cairo-gl-es-v3/

[stuaxo]

The only tricky thing with the cairo-gl backend is that it isn't built on some / most distros by default.

So pycairo would either need a way of toggling it, or maybe supply it's own build.

Personally I think it's a bit of a chicken + egg thing, and if we ever get it working it might encourage more users, and then the distros might re-enable it.

I'm interested in seeing what the path performance is like on GL...

It's going to be a while until I have time to look into getting it PyCairo working with CairoGL or for someone to step forward.

There have been a couple of patches not too long ago to add backends to PyCairo (such as the Tee backend), so at least there are examples.

[briend]

Do you think this commit is the complete patch for the Tee backend? https://github.com/pygobject/pycairo/commit/4b8aba8a971df7915bf00930be04e695256505a2

It is almost comical how many times the GL backend has been turned on, then off, then on again, then off. I wonder what the road blocks are today, in 2018? http://metadata.ftp-master.debian.org/changelogs/main/c/cairo/cairo_1.15.10-2_changelog

Here's an example of what we could do with an openGL backend and OpenColorIO (w/ filmic-blender OCIO configuration): https://youtu.be/XXHOTHyVgrU?t=250

This is a hacked up version of MyPaint (which uses PyCairo). I jammed in python OCIO to do the scene-referred transforms w/ floating point image data, but it is very slow since it is all CPU based. So, even if the gl-backend was the same speed or even a bit slower, it would still be of enormous benefit for this type of program since you're basically getting color management and everything OCIO offers "for free". Whereas, even just doing lcms2 color management in GIMP is known to slow it down considerably: http://www.gimpusers.com/forums/gimp-user/19410-color-managing-slows-gimp-down

More OCIO info for curious: http://opencolorio.org/developers/usage_examples.html

Mypaint OCIO/scene-referred/floating point data example https://github.com/briend/mypaint/tree/OCIO_working https://github.com/briend/libmypaint/tree/OCIO_working

[stuaxo]

My theory is there is a lack of testing. Back in the day the back-end was turned off because it could cause a memory leak with the propriatory nvidia driver, but who knows if that is the case now (I bet it is probably fixed).

I tried making a Cairo PPA for Ubuntu with it enabled, but keeping it working when a new Ubuntu came out was too difficult (which probably explains why all the precious ones failed too).

I'll definitely try all your stuff, just snowed under with non gfx coding for work until at least April 1st

[stuaxo]

That looks like the patch is the one @lazka will know for sure though.

[stuaxo]

Most of the Cairo back-ends have basically the same API, there aren't that many platform specific functions, which is why looking at the Tee patch could be a good start.

[briend]

Thanks @stuaxo, I might take a poke at it but it might be beyond my current grasp.

I'm really hoping I will be able to replace the cairo.ImageSurface(cairo.FORMAT_ARGB32, w, h) with an openGL surface and things magically work (I can dream, can't I?)

[stuaxo]

Maybe just bind some of the APIs that are the same as ImageSurface first.

If thats building then it might not be too much work to add any GL APIs.

[lazka]

cairo is planning to drop all unmaintained/unused backends, including opengl, so I'm going to close this.

[stuaxo]

Do you have a link to the ticket ?

[lazka]

https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/287

[cubicool]

All I added was just a kind of "demo" for using SDL + Cairo; nothing low-level. It would be INCREDIBLE to have GL support--as I still use Cairo in more than half of the "paid" contract gigs I'm involved in--but I understand it takes someone who has more time/knowledge to maintain.

There are 2 libraries uses primarily in gaming that I believe ONLY have accelerated rendering:

https://www.noesisengine.com/ https://coherent-labs.com/products/coherent-gameface/

I've used NoesisGUI a few times. Besides using XAML (yuck!), it's not a bad library at all. Although, if I'm not mistaken, their rendering approach is simply to feed a tesselation library some vector data and then present the result to the underlying GL/DX system. Is that how the old Cairo GL "surface" worked too?

On Fri, Mar 4, 2022 at 12:12 PM Christoph Reiter @.***> wrote:

https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/287

— Reply to this email directly, view it on GitHub https://github.com/pygobject/pycairo/issues/65#issuecomment-1059351444, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIECQXWZLKIW7T2JAGFVG3U6JABPANCNFSM4DVXF3MA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[stuaxo]

believe that is how it worked - I'm not sure what's in the system currently.

While more modern approaches exist in other libraries, such as SDF, I think it's still a promising approach, if not the most efficient everywhere.

There is still cairo-egl-context (for now at least?), I think EGL helps handle connect the window system to GL - https://gitlab.freedesktop.org/cairo/cairo/-/blob/master/src/cairo-egl-context.c

If you just want to integrate pycairo surfaces and SDL with readily installable packages, then pygame can now understand pycairos BGRA image format, I really need to give it a play and see how the performance is like.