bugMyPaint - Bugs: bug #19732, Use GEGL in MyPaint

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #19732: Use GEGL in MyPaint

Submitted by:  Jon Nordby <jonnor>
Submitted on:  Sun May 13 00:51:16 2012  
Severity: 3 - NormalPriority: 5 - Normal
Status: PostponedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: Planned Release: None
Operating System: 

(Jump to the original submission Jump to the original submission)

Mon Jun 23 22:01:22 2014, comment #11:

Hi Andrew,
no I do not plan to continue the GEGL work, mostly due to having moved on to other things.
Of the development I started in this area I am mostly interested to finish the performance improvements. My most recent findings were that this was equally easy (or easier) without GEGL*.

The commit that removed in-progress-but-not-used GEGL code and associated documentation was: https://gitorious.org/mypaint/mypaint/commit/6ec06686d3d7577de8f1940d114d3d96932fc0ca

GEGL will of course continue to be supported in libmypaint as a brush engine backend.

  • This work should however simplify GEGL integration if someone else wants to pick it up, as it massively reduces the dependency on the Python tilebackend.
Jon Nordby <jonnor>
Project Administrator
Mon Jun 23 18:03:06 2014, comment #10:

Hi Jon -

Is this still on the roadmap for 1.2? I'm guessing not, as we discussed at LGM. IMO it would be fine to postpone it till after the release, and make a fuller integration push afterwards.

I've made https://github.com/mypaint/mypaint/issues?milestone=2&state=open for desirable features - I'll leave it to you to migrate this bug there if you're still willing to work on it (Status:Postponed + Closed here plus linking has the right feel).

Andrew Chadwick <achadwick>
Project Administrator
Fri Jan 4 21:54:48 2013, comment #9:

Moving to in-progress, as work has been done. In particular, the performance is now (more than) good enough to start using GEGL.

I hope to complete Milestone 1, using GeglBuffer to back our surface, for MyPaint 1.2.

Jon Nordby <jonnor>
Project Administrator
Thu Jun 14 22:30:19 2012, comment #8:

The steps proposed in comment #6 have now been implemented. In addition, the existing work has been pushed to master.

I've also updated README.gegl to include a TODO section with milestones/tasks. https://gitorious.org/mypaint/mypaint/blobs/HEAD/README.gegl

I fear that milestones 1-3 may not be realizable independently, though I hope that it is.

Jon Nordby <jonnor>
Project Administrator
Wed May 16 06:25:38 2012, comment #7:

In case you're going to struggle with the build system anyway, let me just add that I would be happy if we can switch to distutils instead of scons. A possible path of migration would be to not use scons any more for newer stuff.

Martin Renold <martinxyz>
Project Administrator
Tue May 15 21:38:15 2012, comment #6:

Proposed next steps:
lib/document.py: Make GDKPixbuf and other pyGTK based dependencies optional. This should allow it to be used in the mypaint-gegl.py demo application.
gui/tileddrawwidget.py: Refactor out eventhandling into a Gtk.EventBox subclass. The view widget to be used in MyPaint will then be a TiledDrawWidget inside this eventbox. gui/document.py might also be influenced by this change. This should make it possible to reuse this widget in mypaint-gegl.py, where the view widget would be a GeglGtk.View inside the eventbox.
May also require removing/making optional dependencies on other widgets from tileddrawwidget.py

These are both changes that could hopefully go into master.

Jon Nordby <jonnor>
Project Administrator
Tue May 15 21:10:41 2012, comment #5:

Just a note about the criteria for going switching to GEGL in MyPaint. The GEGL based implementation needs to:
1) Be feature complete
2) Render the same way
3) Not be significantly slower. Say be within ~20%

Jon Nordby <jonnor>
Project Administrator
Sun May 13 03:41:11 2012, comment #4:

On a related note. Martin investigated moving to using 32bit floats instead of 16 bit integers for the brush engine. This is wanted when using GEGL so that standard operations can be used without color format conversions*.
Drawing performance remained very close across different brush sizes. The main issue is that memory consumption will be twice as high. Hopefully once we use GEGL this will be OK as GeglBuffer can transparently keep the buffers on disk instead of in memory.

  • The alternative is to implement fast-paths for our 16bit integer format to all the GEGL operations we want, but that is probably not worth the effort.
Jon Nordby <jonnor>
Project Administrator
Sun May 13 03:23:10 2012, comment #3:

Because one cannot combine PyGObject (required for GEGL and GEGL-GTK) with PyGTK in a single application process, we would need to complete that work before this could be integrated. See bug #19230

Jon Nordby <jonnor>
Project Administrator
Sun May 13 03:05:37 2012, comment #2:

Current status:

There is now a "gegl" branch available in the mainline MyPaint repository. See README.gegl for how to test/develop.

In this branch is a working Surface implementation based on GeglBuffer, as well as load/save support for PNG files.

There are a number of (mostly easy-to-fix) issues that would need to be fixed in the GEGL project for MyPaint to use it. See

Jon Nordby <jonnor>
Project Administrator
Sun May 13 01:11:29 2012, comment #1:

Implementation strategy for initial porting:
1. Brush engine: Use a GeglBuffer to back the Surface API instead of lib/tiledsurface.{hpp,py}
2. Document model: Let each Layer have a GeglNode representing that layer. Compositing is done by a GEGL graph that combines these nodes together. This removes the need for lib/pixelops.hpp and lib/composite_rgbx.hpp
3. Import/export: Use GEGL file operations like file-png and file-jpeg instead of GdkPixbuf and lib/fastpng.hpp
4. Rendering: Use GeglGtkView from the gegl-gtk library instead of gui/tileddrawwidget.py. Pass the GeglNode of the composited node to the widget.

Jon Nordby <jonnor>
Project Administrator
Sun May 13 00:51:16 2012, original submission:

Use GEGL as the backend for image processing instead of the current custom code.

The motivation behind this change includes:

  • Allow to operate on larger-than-RAM images
  • Make it easy to add new features that involves image processing
  • Make the MyPaint brush engine available to other projects
  • Help make GEGL an excellent libre graphics processing library
  • Perhaps make it possible to make use of OpenCL & OpenGL on supported systems to increase performance
  • Perhaps make it possible to inter-operate more closely with other applications
Jon Nordby <jonnor>
Project Administrator


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by achadwick (Posted a comment)
  • -unavailable- added by achadwick
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by jonnor (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Jun 23 22:01:22 2014jonnorStatusIn Progress=>Postponed
    Fri Jan 4 21:54:48 2013jonnorStatusWish=>In Progress
    Wed Nov 28 11:45:52 2012achadwickCarbon-Copy-=>Added achadwick
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup