[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: High-level pixel access methods
From:       Boudewijn Rempt <boud () calcifer ! valdyas ! org>
Date:       2004-02-15 12:43:56
Message-ID: 200402151343.56353.boud () valdyas ! org
[Download RAW message or body]

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?

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

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.

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]