MyPaint and GEGL: porting evaluation begins

MyPaint and GEGL: porting evaluation begins

GIMP and MyPaint projects have a closer relationship than one might assume. And there’s a chance they could get to the next stage.

The driving force behind that is Jon Nordby, a MyPaint developer who earlier created an OpenRaster loader and saver for GIMP. Thanks to Jon, GIMP 2.8 is the first app’s version that is out-of-box capable of exchanging multi-layered images with MyPaint, Krita and Pinta. And it looks like Jon isn’t stopping at that.

How It Began

Last year Jon started a couple of infrastructure projects, gegl-gtk and gegl-qt, that simplify creating new GTK+ and Qt applications based on GEGL, a new GIMP’s image processing library that solves oh so many issues with the current GIMP.

The point was to evaluate if MyPaint could use GEGL. Why? In November last year Jon stated during an interview:

I believe that GEGL has a great potential in increasing the software reuse and improving document interchange between libre graphics applications... Nothing has been decided about GEGL and MyPaint, but the idea is to use GEGL in MyPaint for the graphics processing.

The evaluation process is now taking place: Jon recently announced that now there is a simple application available in a branch of MyPaint that allows choosing a MyPaint brush and painting with it on a GEGL-backed canvas.

MyPaint/GEGL test app

Interestingly enough, this announcement nearly coincided with a public availability of another new project. Two weeks ago sigetch, who had created the GIMP Painter fork earlier, announced his port of the MyPaint’s brush engine to GIMP. Whether this feature will be used in upstream GIMP, remains to be decided upon, as there are several technical and user interaction concerns.

Mating GIMP And MyPaint, with Jon Nordby

We asked Jon for an update on his plans regarding MyPaint, GEGL and GIMP.

Jon, do you think sigitech's project — porting MyPaint brush engine to GIMP — is helpful in any way for interaction between GIMP and MyPaint?

I think the project can be useful in showing how new paint tools can be integrated into GIMP. I do not think that copying the MyPaint brush engine into a different project and then modifying it to fit the target project is a good strategy long-term however.

Whenever the MyPaint brush engine is updated with fixes or new features in MyPaint, these copies then have to play catch-up or risk being unable to use or incorrectly render new or current brushes.

That is why I think MyPaint needs to provide a library or plugin that is reusable by other projects without modification.

Talking of big wins when using same library as in GIMP, do you think the GEGL-based MyPaint would be able to share buffers with GIMP, so one could use both apps to work on one document, or two people could work on it over network?

Øyvind Kolås (lead developer of GEGL — LGW) has said that GeglBuffer is designed with sharing between multiple processes in mind. So working on a single layer in a document from two applications should be possible with buffer sharing.

Sharing and operating on an entire multi-layered document requires more work because both applications needs to have a common understanding of the document structure.

It is one of the things I’d like to try out. Maybe such integration would help fend off all the people who want 1 000 000 features in MyPaint that GIMP already does and has thought-out interactions for :)

Let’s get back to your experiments. What is the main criterion in the evaluation with this testing app you created?

The critical thing is performance. I am confident that GEGL can provide feature parity and render documents in a compatible way with existing MyPaint. So key question is whether we can get equivalent performance, and how much work it takes to get there.

Painting in the application is very slow right now. Is it a MyPaint issue, a GEGL issue, or both?

A combination of MyPaint, GEGL and GEGL-GTK issues. The raw performance of the GeglBuffer based brush engine is currently about half of what the native MyPaint brush engine can provide. The performance is limited by the overhead in fetching a tile/region from the GeglBuffer.

The native engine caches such access, and by adding API to GeglBuffer that guarantees that the memory backing the buffer does not change we can do the same for the GEGL based engine. I also have an idea on how to limit the frequency of tile access by reordering the drawing of dabs.

However, I doubt that the poor performance observed in the test application is directly due to the brush engine limitations mentioned above. I have yet to analyze drawing performance in when the UI is included, but I know a couple of issues already.

One is that we currently invalidate the buffer every time we access a tile/region, which currently is for every dab. This triggers a lot of unnecessary processing and redrawing. What we actually want is to invalidate the buffer once per stroke. Again adding new API to GEGL will allow the MyPaint engine to do that and improve its performance.

GEGL-GTK could also combine multiple invalidations of the same region and process it in one go.

Are there any specific changes in upstream GEGL required to complete GEGL-based version of MyPaint?

Yes. The current ones are listed here. I will add any other issues I find as dependencies to that bug, so it should stay current also in the future.

What are your project priorities, and how can contributors help you?

GEGL in MyPaint is basically still in the research stage. I'd like to pretty quickly get to a stage where we can evaluate whether to switch to GEGL. I have added the criteria for such a switch here.

I try to document what needs to be done, and (on a high level) how it can be done in the bug-reports. Anyone who wishes to help is encouraged to jump in! Join the mailing list and say what you wish to work on, and ask if you have any questions.

Meanwhile In GEGL...

There is a planned project that will help making GEGL leaner. In two weeks Isaac Wagner, a Google Summer of Code student, is starting to work on a GEGL-based node editor. The new app will serve as guinea pig to discover deficiencies in the library and try some user interface ideas. Two more students will be porting GIMP filters to GEGL.

Was it useful? There's more:

10 Responses. Comments closed for this entry.

  1. Great interview. Thanks!

    All this GEGL hype is very interesting. I’m very curious what the future will bring :)

  2. Alexandre Prokoudine 18 May 2012 at 12:33 am

    Robots. There will be many robots in the future :)

  3. I KNEW IT! They said I’m a madman, but I know I’m right! >:]

  4. shared buffers! that sounds great. People could paint collaborating at the same time. :D i never thought gegl was so important. butthe interaction between apps is always welcome. Good job , Jonnor and Great interview as alwys Alexandre

  5. Alexandre Prokoudine 18 May 2012 at 6:50 pm

    There was a project for sharing images between Blender and GIMP, called Verse: It was an early attempt to solve the sharing issue. The last time I asked the developer was interested in a GEGL kind of approach.

  6. Seeing as just how many GIMP and MyPaint-like features people are wanting in Blender, especially around texture painting and generation being able to inter-operate more closely would avoid a lot of reinvention.
    Blender could also make use of GEGL operations in its node compositor.

    But I don’t have the time for that…

  7. the first step for a “libre creative suite” is (in my opinion) inter-operation between graphic applications… GEGL will bring great innovations in all senses and in many applications Good job guys and thank you!

  8. I dont’t know that much about GEGL, but I think it can be like a glue (like PHP is for web applications) for CG applications :) in this way we, FOSS users, can have the interoperability that Adobe implements in his creative suite.

  9. What I would really love to see in Gimp are MyPaint’s non-destructive canvas rotation and flip/mirroring.

    And/or some basic image editing functions in mypaint, like selections, resizing, deforming and cropping the final size. I have to alternate between both to compensate for the shortcomings of each, like using Gimp to create a template for MP with the desired resolution/DPI. That’s not so terrible anyway, perhaps the better way to go would be to have a smarter way to both work on the same file at the same time, like both being aware that they’re editing the same file and updating it after it somehow “perceives” that something was done in the other app. Not necessarily/preferably not in real time, as it would probably use a lot of CPU. But some inner “screen saver” type of thing, each app start counting when it’s not used and then pay attention to some cache or whatever, and when it’s focused again, it updates that cache. But that is unlikely to be something that can be cross-plataform I guess.

  10. Somehow I missed the “shared buffer” part, that is probably a better solution for what I’ve mentioned at the end of my comment. Unless it demands signifcicantly more CPU. Ideally it would be somewhat like two or more window views on Gimp alone, which does not use much more CPU I guess.