Buiding with GEGL Support Enable Fails

[odysseywestra]

Building libmypaint with the --enable-gegl flag raise cause make to halt saying make[2]: *** No rule to make target '../libmypaint.la', needed by 'libmypaint-gegl.la'. Stop. I think we might have missed something when upping the api to 2.0. Right now it's affecting our AUR pkgbuilds which use libmypaint-git for gimp-git and mypaint-git as a dependency.

@achadwick could you look into this since you made the changes for the API version?

Steps to Reproduce from Git Folder

1. ./autogen.sh
2. ./configure --enable-gegl
3. make -d

[mytbk]

0b31421 is the commit that breaks gegl build, but I still don't know why.

I have changed gimp-git dependency libmypaint-git to libmypaint, you can update the gimp-git PKGBUILD and use libmypaint instead.

[odysseywestra]

@mytbk I've updated the libmypaint-git to temporary disable the gegl build for now until we can get this fix. So I believe you can safely switch back if you wish.

[achadwick]

The standard configuration of libmypaint does not build against gegl, and that is what we should ship. Last I heard from the GIMP people was that libmypaint does not need to be built with gegl for GIMP to build against it.

Serious Q: should we drop GEGL support?

Since I've no GEGL knowledge, and since the developer who introduced GEGL support is unfortunately no longer active, this would suit me OK. MyPaint does not use gegl, and it would be quite a pain to switch over to it... so we haven't.

(I know. I'm a total "don't change anything!" maintainer-head)

[odysseywestra]

I'm in the camp that we should not drop GEGL support due to its advantage of using the GPU and CPU for rendering. As the brush engine gets more complicated and especially if we plan on implementing #6(custom dabs shapes), it's going to need the computing power. I say before we even consider dropping support, we should reach out to the Gimp/GEGL developers to see if any of them will be willing to take up the mantle.

[briend]

@odysseywestra but it sounds like MyPaint doesn't even use GEGL, so it can't even use the GPU. In fact, it doesn't sound like GEGL uses the GPU much since there are bunch of operations left to port over to OpenCL: https://github.com/OpenCL/GEGL-OpenCL/issues
Please correct me if I'm wrong. I would love to see GPU acceleration but it would probably need a huge rewrite of both MyPaint and the engine. Maybe using GTK's new GTK+ Scene Graph Kit (GSK) which has Vulkan rendering (which OpenCL will merge with eventually) will be the way to go in the future? Again, I don't really know what I'm talking about so hopefully someone else can clarify this.

[odysseywestra]

When we were using scons for building MyPaint, the option for enabling GEGL was there. I guess that option was lost when we transition to using setuptools. Probably want to open a new issue on MyPaint's repo to add that option to setuptools.

And yes while the operators don't use OpenCL, the core parts of GEGL have the ability to use it. Besides right now, I don't think the brushengine is using those operators from what I see, but I could be wrong.

In the end, I still think we need the brushengine to utilized both the CPU and GPU. GSK seems like a promising alternative. We'll definably want to look into it more.

We also should take a look at MyPaint and libmypaint's PERFORMANCE docs. Some pretty interesting ideas @jonnor had.

MyPaint's: https://github.com/mypaint/mypaint/blob/master/doc/PERFORMANCE

libmypaint's: https://github.com/mypaint/libmypaint/blob/master/PERFORMANCE

[Jehan]

I fixed libmypaint-gegl build. As for the discussion of whether or not keeping it, I'd say that I understand if you want to get rid of this if neither you nor anyone uses libmypaint-gegl.

Ideally MyPaint could make good use of GEGL though. The more projects use it and contribute back, the better it will get with time for everyone to use. :-) So it all depends if that is in your plans or not in the longer term.

[briend]

I wonder if we shouldn't focus more on OpenMP for now. @jonnor already added a couple parallelization loops in the engine with openMP directives. I wonder if we could find more areas to add the directives. Another neat thing is SIMD which can be much better than parallel threads.

Does anyone think any of the loops in brushmodes.c might be candidates for this SIMD optimization?