Whoever tried experimental version of GIMP and thought that GEGL is slow will need a lie-down now. Performance tests revealed that GEGL-based version of MyPaint could be up to 4x faster than the stock one.

A year ago LGW interviewed Jon Nordby, one of MyPaint developers, who at the time started evaluating GEGL (GIMP's next image processing core) as a possible replacement for MyPaint's rendering engine. His reasoning:

I believe that GEGL has a great potential in increasing the software reuse and improving document interchange between libre graphics applications. It already has a good framework for generic graphics processing, enabling things like on-demand processing, non-destructive editing and high bit depth.

In May 2012 Jon created a preliminary port to GEGL, stating: “GEGL in MyPaint is basically still in the research stage”. Forward 6 months to present days:

Users of the soon-to-be-released MyPaint 1.1 should experience about 15% faster drawing of strokes for medium to big brushes. Switching to the GEGL-based back-end for MyPaint 1.2 is now both feasible and highly desirable from a performance perspective.

What happened?

Jon set several goals for himself: ensuring that the switch to GEGL doesn't compromise performance, that applications that use MyPaint's brushlib are fast, and that MyPaint gets faster itself. So he did quite a bit of optimization work that he characterizes as preliminary, which, however, resulted in aforementioned 15% speed-up of the existing MyPaint's rendering engine.

The three used techniques are:

accumulation of dabs for further processing instead of fetching and updating tiles after each dab; splitting processing of tiles between processing threads; fine-grained parallelism using SSE via GCC's autovectorization.

The existing rendering engine doesn't use multithreading yet, because tiles are not thread-safe. Unlike the GEGL-based version of MyPaint.

IM IN UR MYPAINT, GEGLIN

Now the GEGL based version of MyPaint is 25% faster even with a single thread, and 100% faster for 2 threads, and that's all for big brush sizes. As the test clearly indicates, with 6 threads, the GEGL-based version is up to 4 times faster. Here's the meat:

That was measured by Jon against two different versions of MyPaint with a charcoal brush. Blue square is the old rendering engine, red square is GEGL-based rendering engine working on 6 cores. The other ones are GEGL-based version with 4, 2 and 1 cores respectively. You get the picture.

However, it is definitely too late include this in v1.1, so this is at least v1.2 material. The code needs more checking, more polishing, and a lot more testing.

What's next?

As for the existing rendering engine, Jon states that it's all just the beginning, and only a fraction of MyPaint's code is vectorized. The maintained list of things to do mentions the following possible directions:

more code vectorization;

improving memory layout to have better cache line alignment;

experimenting with different tile sizes;

caching brush dab masks;

leverage processing to GPU.

If you are interested to have a go at Jon's branch with GEGL-based rendering, clone the official Git repository and read the README.gegl document.

Also, check out Jon's blog post and his even earlier mail to the developer list for more details.

How soon is MyPaint 1.1?

MyPaint 1.1 is currently being finalized. Yesterday Martin Renold sent an announcement to translators to notify that the team is giving them 3 weeks to finish their work on localization of the user interface. The final release will quickly follow unless some nasty bugs turn up, says Martin.

Expected new features in MyPaint 1.1 include, but are not limited to:

more layer modes;

new color palettes;

mirrored painting mode;

drawing lines and ellipses with the current brush.

The feature image of this blog post is a painting by David Revoy created with MyPaint.