High-level pixel access methods

[Patrick Julien]

On February 15, 2004 07:43 am, Boudewijn Rempt wrote:
> On Sunday 15 February 2004 13:34, Patrick Julien wrote:
> > I am not disputing this, nor am I trying to prevent having a getPixel and
> > setPixel like functions.  Simply stating that placing these operations in
> > KisTileMgr would result in an almost an identical implementation.  So,
> > yes, they would be just as slow.
> >
> :-(. The slowness is because of the copying, I guess. Isn't there a way to
>
> avoid that?

Yes, using an iterator to hide the copying.  However, that being said, this 
isn't just because of the copying, but the repetitive calls and copies being 
made.

>
> Anyway, would it be an idea to move the filling of the KoColor to the
> colour strategies? Now we have:

I don't like KoColor, used to be KisColor FYI... but the problem is that we 
need color profiles, and I feel silly saying:

"To add a new color space to Krita, you need to add a color strategy... oh, 
and yeah, modify KoColor too."

So, no, keeping KoColor wasn't really part of the overall plan.

>
> switch (m_alpha ? typeWithAlpha() : typeWithoutAlpha()) {
>         case IMAGE_TYPE_INDEXEDA:
>         case IMAGE_TYPE_INDEXED:
>                 break; // TODO
>         case IMAGE_TYPE_GREYA:
>                 data[PIXEL_GRAY_ALPHA] = opacity;
>         case IMAGE_TYPE_GREY:
>                 data[PIXEL_GRAY] = upscale(c.R());
>                 break;
>         case IMAGE_TYPE_RGBA:
>                 data[PIXEL_ALPHA] = opacity;
>         case IMAGE_TYPE_RGB:
>                 data[PIXEL_RED] = upscale(c.R());
>                 data[PIXEL_GREEN] = upscale(c.G());
>                 data[PIXEL_BLUE] = upscale(c.B());
>                 break;
>         default:
>                 kdDebug() << "Not Implemented.\n";
>                 break;
>         }
>
> And that looks a bit wrong to me.