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

comparing gimp speed

This discussion is connected to the gegl-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.

2 of 7 messages available
Toggle history

Please log in to manage your subscriptions.

comparing gimp speed David Neary 12 Nov 14:17
20041111200108.A83F110DDF@l... 07 Oct 20:29
1100204893.26744.16.camel@p... 07 Oct 20:29
4193F2E1.50706@fakenhamweb.... 07 Oct 20:29
ef010f7404111116136c7e2d2b@... 07 Oct 20:29
728B29AE-3496-11D9-90F3-000... 07 Oct 20:29
  comparing gimp speed Øyvind Kolås 12 Nov 18:42
David Neary
2004-11-12 14:17:54 UTC (over 19 years ago)

comparing gimp speed

Hi,

Daniel Egger wrote:

It would be really cool if the pixel data addressing was pluggable so one could easily write a different storage backend. On top of my head there would be several schemes I'd like to try: - A simple linear memory segment with COW for new layers - dito but with RLE compression (and thus more complex addressing) - Line based addressing with COW and aliasing for duplicate lines, with LUT for each line
- Planar memory segments (Shoot now! ;))

I don't know what GEGL will buy us exactly because we certainly need a change from "store those 32bit RGBA values" to something more variable but IIRC GEGL is only about pixel composition, not storage.

There are better people to talk about this than me (Dan, are you reading?) but part of gegl is about data representation, and that includes its representation in memory (tiles, scanlines, whatever). I know that Dan Rogers was working on a GeglTiledImage structure at one stage, which had its own tile manager. Given the object structure, perhaps some of the alternate schemes you describe could be accomplished by inheriting from GeglImage and implementing the extra bits.

Cheers, Dave.

Øyvind Kolås
2004-11-12 18:42:44 UTC (over 19 years ago)

comparing gimp speed

On Fri, 12 Nov 2004 11:34:35 +0100, Daniel Egger wrote:

It would be really cool if the pixel data addressing was pluggable so one could easily write a different storage backend. On top of my head there would be several schemes I'd like to try:

- A simple linear memory segment with COW for new layers - dito but with RLE compression (and thus more complex addressing) - Line based addressing with COW and aliasing for duplicate lines, with LUT for each line
- Planar memory segments (Shoot now! ;))

I don't know what GEGL will buy us exactly because we certainly need a change from "store those 32bit RGBA values" to something more variable but IIRC GEGL is only about pixel composition, not storage.

GEGL is about image compositing, not pixel compositing, thus it has to deal with efficient memory representations as well. In my view of how things will be after a full integration, gimp uses GEGL for all it's image processing needs, even the paint tools will most likely be reimplemented to use GEGL.

The largest problem with making the image representation pluggable is that it either complicates op (short for image operation, plug-ins in GEGL) development or adds overhead due to additional copying of values needed to provide a simple interface.

Layers (or their equivalents after GEGL integration) can theoretically be unbounded surfaces instead of square,. there are various ways to such sparse allocation of images, and IIRC the tile based caching system Dan implemented in gegl/gegl/image would allow this.

After integration of GEGL various other speedups can be achived, by for instance caching static portions of the compositing graph, other optimizations and rearrangements are also possible on the graph level.

/pippin