[Gegl-developer] Re: [Gimp-developer] comparing gimp speed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
        David Neary,
        Lyon, France
   E-Mail: bolsh@xxxxxxxx
CV: http://dneary.free.fr/CV/

[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux