home contents changes options help

by Robin Rowe 3/2/04

In response to my paper below, I've heard from a GEGL developer that the original 2000 GEGL design document "information is woefully and horribly out of date", and further that no better documentation exists. Nobody can compare anything to GEGL's intended architecture because it has yet to be revealed. A GIMP evangelist suggested to me that, "the definitive reference for current gegl thinking is the source code and unit tests in the gegl module of CVS". However, this is no architecture reference.

To check out the gegl CVS module:

% export CVSROOT=:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome

% cvs co gegl

Without any accurate docs, the GEGL CVS code is very difficult to dive into. It is not obvious where to start and CVS includes GIL, code reportedly abandoned. CVS also includes the outdated misleading docs mentioned above. Anyone quickly scanning the code to deduce architecture can expect to become hopelessly confused.


by Robin Rowe 2/29/04

CinePaint and GEGL use two different architecture approaches. How different they are is the subject of this paper.

Because CinePaint exists today as a release, and GEGL does not, it can be confusing comparing the two. To try to make the comparison equivalent, this paper describes where we think CinePaint will be in 18 months to two years, the time frame that GIMP is anticipating to complete GEGL.

The GEGL project according to the GimpCon presentation September 22, 2000:

Pixel manipulation will be done using GEGL (Generic Graphics Library). GEGL abstracts the color model and color depth (8-bit, 16-bit, float) and provides generic data types for channels or colors. The algorithms implemented using these abstract types are converted to the actual C code using a code-generator. That way it's easier to add additional data types and color models and optimizations.

Built on top of this, the GIMP core will implement objects like images, tools, layers, channels, brushes etc.

Each node (comparable to a layer in current gimp) may compute its data internally as pixels, vectors, text, or whatever....

The communication between the core application and the plug-ins will be done using CORBA.

To summarize, GEGL is based on a node architecture with every object being derived from GtkObject. It handles raster images as tiles. It has a node parser based on yacc/lex that is called GIL. (Couldn't find any documentation on GIL.) Code written in C. C++ is not allowed. Plug-in communications is via CORBA.

CinePaint is based on a layer stack, not nodes. Layers are images that may be made up of a single color channel or multiple color channels such as RGB or CMYK. Channels are not necessarily colors, but can be alpha (transparency) or Z (depth) and other types. Channel types can be raster-based or vectors. Layers and channels will have a simpler, more predictable structure than our current layers/channels/masks architecture. Channels will be required to always reside in a layer, and masks will simply be channels.

It isn't possible to anticipate all the channel types one needs, and adding channel types to a rigid core can be difficult. GEGL's answer to this is to make all layers abstract nodes derived from GtkObject and develop the GIL code generator to build new channel types and operations. CinePaint takes a simpler approach, treats layers as memory with a pointer to a plug-in that knows how to handle that memory.

CinePaint inherited the GIMP tile design that divides large images into a mosaic of tiles in memory. In theory this can be more efficient that scanlines, but that has not generally proven to be the case. GEGL is staying with tiles, but CinePaint is moving toward scanlines. CinePaint has a strategy of maintaining backward compatibility, to not break existing plug-ins that use tiles.

CinePaint uses C++ code with C APIs. Plug-in communications is via fast direct memory access using pointers and threads, not CORBA.