cbr at boemann.dk
Mon Jul 5 23:13:49 CEST 2004
> The current implementation of iterators shows the way forward, and perform
> quite surprisingly well, but we'll need to extend and refine the
> implementation, and carry forward the use of iterators throughout Krita so
> that it becomes the only way to access image data. Direct tile manager
> should be discouraged, if not made impossible (can C++ do that? no package
> private classes, are there?).
> The tile manager loads image data on demand from Krita's file format,
> and, where possible, from other image types that allow on demand loading
> of portions of the image.
Perhabs but if so it needs to be decoupled.
> The tile manager manages undo data (currently it's KisPainter that does
> but it makes sense to push this responsibility down).
yes there are benefis to that, but the way we do this should be thought
> * Iterators
> Iterators offer random and linear read/write access to channels, pixels
> 2 dimensional arrays of pixels.
Not channels, and 2 dim arrays just complicates things.
> Iterators return pixel data as a vector/array (whatever, but preferably
> a pointer to a amorphous chunk of bytes*) of bytes which can be
> by the colour strategy as a colour.
> *) Although I can probably be talked out of that by showing me some real
> perfomance measurements. Always having to check boundaries will soon
> real pain.
No checking is needed.
> Colour strategies can render their pixels to display RGB format (i.e. a
Yes but later it should be done with the aid of lcms that gives us ICC color
More information about the kimageshop