Const iterators

[Casper Boemann]

On Monday 28 March 2005 18:15, Adrian Page wrote:
> Boudewijn Rempt wrote:
> > Is it maybe an idea to add const iterators for the paint devices some
> > time soon? I'm everlastingly either const_casting or removings consts
> > because I cannot read out a device const'ly...
>
> Yes, we should have const iterators, or at least a way to access the
> data in a read-only manner.
KisROPixel does just that IFAIK

> I have been looking at the iterators lately and have thought about
> making some changes like this. We could make rawData() return a const
> Q_UINT8 *, and maybe have a function to copy into the data:
>
> const Q_UINT8 *rawData()
> void setRawData(const Q_UINT8 *src, Q_INT32 numPixels = 1)

It requires an extra memcopy, over the current usage.
And blitting is not all that fast already.

> An advantage of having a function to do the job of the memcpy is that we
> could track the exact extent of the data without having to do the pixel
> search that you do in exactExtent. Then everything that would benefit
> from an exact extent could just use it without having to think about it.
But exact extents are only useful for bounding box presented to the user
Not something that is done all that often as compared to blitting...

> The same idea would apply to the KisPixel access. Instead of a KisPixel
> pointing to the raw data, allowing you to modify it directly, KisPixel
> would hold its own data and you would do an it.setPixel(pixel) to write it.
>
> Another idea is to make iterators easier to use by being able to set and
> get QColors directly (until we replace QColor with KisColor). Either
> that or allow KisPixels to be settable to a QColor and return a QColor -
> no matter what colour space is in use.
>
> It would be nice to be able to do things like
>
> KisHLineIteratorPixel pixelIt = createHLineIteratorPixel(...);
>
> QColor color = pixelIt.color();
> ... do something interesting with the color...
> it.setColor(color);
>
> The main thing is to hide the colour strategy and its
> nativeColor/toQColor etc, and just let you concentrate on the algorithm
> you're implementing. It would be good to hide the raw data access,
> memcpys, etc, particularly for people who are new to the code and, say,
>   want to write a simple plugin.
>
> Currently accessing the data through KisPixel is a start but it still
> requires the use of colour strategies, which would be better hidden,
> although there for advanced use.
I think that KisPixel should be how we do that. There shouldn't be a need for 
yet another structure. It KisPixel lacks somethin then we should change 
KisPixel, not invent something new again.

But doing something to make a readonly iterator return const is certainly 
something we could do.

-- 
best regards / venlig hilsen
Casper Boemann