RSS/Atom feed Twitter
Site is read-only, email is disabled

GEGL Developers (what is pippin doing)

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

1 of 1 message available
Toggle history

Please log in to manage your subscriptions.

GEGL Developers (what is pippin doing) Øyvind Kolås 09 Jan 09:37
Øyvind Kolås
2006-01-09 09:37:47 UTC (almost 19 years ago)

GEGL Developers (what is pippin doing)

On 1/9/06, Leon Brooks wrote:

OK, so what do Eric, Florent, myself and others here lurking who are interested in putting a rocket under GEGL need to do to get this show back on the road on a more permanent and ongoing basis?

How hard is the storage code to write? Would it make sense to co-opt an existing storage management system from elsewhere? What can _I_ do? I code but am not a graphics guru of any sort.

The gegl code base needs cleanup, but the main problem I see with GEGL is that since I have gotten involved GEGL has never actually been processing images, if anyone could make GEGL actually process images, even if it means just using linear buffers (perhaps by digging in CVS for older versions that might actually have worked.). It would be a great step for GEGL.

I am currently "thinking" about data storage management, this thinking might take some time.

One aspect which is important when it comes to developing this code is that it needs to integrate both with gegl, and gimp. Another issue to keep in mind is that the API used to access the data storage system will become the painful API needed to efficiently handle image data in gimp/gegl, in much the same way that people need to familiarize themselves with tiles when writing plug-ins for gimp. Keeping things simple at the "end-developer-level" should be a goal.

There is existing code in the gegl/image directory is a previous attempt at a storage model. I have failed to get a understanding of how much of the problem is solved by the code in gegl/image, and whether it has any shortcomings. I feel I do not have enough experience with storage models to make a good decision, which is why I am playing in a sandbox called horizon[1] trying to figure some aspects of it out with code that is actually processing pixels. The data storage management in horizon is aiming high in an attempt to discover as many possible requirements as possible.

I am developing horizon as the backend for a sketch/scribble/paint/personal information storage system for a tablet device from Nokia. The codebase is still under expansion and internal api's haven't started to settle yet.

/Øyvind K.

1: http://pippin.gimp.org/horizon/ --
«The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/