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

List:       kde-kimageshop
Subject:    Re: Mipmapping for canvas. Ideas and comments.
From:       Dmitry Kazakov <dimula73 () gmail ! com>
Date:       2009-07-23 14:47:23
Message-ID: ae32c1ef0907230747q1175aeb0wf55cf8030efdaad2 () mail ! gmail ! com
[Download RAW message or body]

>> > In such a case, color conversion will be done after mipmapping and for
>> > every zoomlevel seperately?
>> yes when creating the prescaledprojection you would also do the color
>> conversion.
>
> There are two sides: only color correcting the scaled pixels will be a lot
> cheaper, but I'm not sure whether that will give visible artefacts.

Hmm... I thought just the opposite: in case you delay color
conversion, you'll have to color-convert every time you change
zoom-level, but in case you do it during updating original image,
you'll do it only once.

Maybe you are right with delaying it... Color conversion shouldn't
depend on the scale much - it's almost linear operation...


> In any case, I'm not officially getting confused myself about mipmapping the
> projection... I'm fine with either doing it in krita/image and using KisPaintDevice,
> or doing it in krita/ui/canvas, and using QImage-based tiles (like the opengl
> canvas does already).

I don't think we should move it to krita/image, as opengl canvas seems
not to depend on our internal prescaling. It seems to have it's own
mipmapping, downsampling and more than that it does it with the help
of gpu. ( Lukas, am i right? )

At the moment, i think the best way would be the following:

1) Pyramid replaces current KisProjectionCache.  And
KisPrescaledProjection requests it for all scale operations.
2) Pyramid uses quite modificated "paint device" based on tiled data
manager class.

class "KisSimplifiedPaintDevice" {
private:
     KisDataManager m_dataManager;

public:
     void loadFromUsualPaintDevice(KisPaintDeviceSP sourcePaintDevice,
QRect rect);

     QImage converToQImage(QRect rect);

     // Here is the difference from usual paint device
    KisSimplifiedPaintDeviceSP getDowsampledByFactor2();
    void setMonitorProfile(KoColorProfile*);
};

What is the difference from regular paint device and why should we
create new class?
i) We leave a path for future experiments: should we color convert
before or after downsampling. We can choose inside the class where to
do it.
ii) Downsampling is moved to lower level.

What do you think?



-- 
Dmitry Kazakov
_______________________________________________
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]