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.
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.