Const iterators

[Boudewijn Rempt]

On Monday 28 March 2005 22:12, Adrian Page wrote:
> Boudewijn Rempt wrote:
> > Wouldn't that slow down all write operations quite a bit --
> > adding a
> >
> > if x < m_x; m_x = x;
> > if y < m_y; m_y = y;
> > if x > m_width; m_width = x;
> > if y > m_height; m_height = y;
> >
> > for every pixel we write?
>
> It would, but I was thinking the default behaviour would be to update
> the extent for every write, but you could disable it and update the
> extent manually after you've finished the updates. I would imagine this
> would be done most of the time anyway, but you have the fallback that it
> does the job for you if you don't.
>
> Another option is that we always update the extent manually after doing
> some writes.

Hm... I don't think that that's ideal -- it would be a source of nasty bugs, I 
guess. I rather like the simplicity of our current iterator api -- it's 
amazing how much you can do with it.

> > This is a bit trickier -- ideally, you want to preserve data that cannot
> > be in a QColor, like wetness/opacity/thickness etc -- and if you convert
> > to QColor and then write, you would lose all the extra data.
>
> True, but I'm thinking more along the lines of our KisPixel object in
> which we have colour channels, an opacity, and 'substance' channels
> (going by the description). Maybe it's too simplistic but I wondered if
> it would be possible to manipulate the colour channels via
> QColor/KisColor, independently of the others. So you would only touch
> the colour channels and leave the rest as they are.

I didn't have time to do more work on Wet & Sticky because of the release -- 
but that's more or less the way I was going to implement compatibility with 
the filters that wouldn't know about wetness etc. But it needs some 
experimentation to see whether it would work. Of course, there are situations 
were QColor won't cut it, because of channel depth or conversion issues. 

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050328/907e9249/attachment.pgp