Solution for the grayscale selections

[Dmitry Kazakov]

> If we want to mix this work with optimization, then we should call it a
> bit differently: "we need to be able to handle
>
>> colorspaces with a *separate* alpha channel".
>>
>> On Sunday I thought about an idea of passing the separate alpha to bitBlt
>> as well. Here are the conclusions which I came to:
>>
>> 1) It will give us *some* opportunities for structural optimizations. We
>> will be able to handle the case of uniform coloring (the most common case)
>> much more
>> efficiently. I can't tell how much speed it will give.
>> 2) It will *not* give us much opportunities to use vectorization, because
>> the pixels in the layer will be laid out in a standard way. Only scaling of
>> the whole mask
>> will be optimized here.
>>
>
> For most if not all composite ops, the formula to calculate the result is
> the same for all color channels, so we can vectorize that easily. We do not
> have to completely change to a planar pixel representation.


I understand that. But to use vector instructions we need that both source
and destination have a separate alpha plane. But that is hardly doable for
the paint devices we store at the layers, at least without
rewriting/hacking the biggest part of pigment and quite a big portion of
Krita. If at least one operand is interleaved, we will not be able to use
vector optimizations.



> Well, it is not too generic actually, because it either adds
>> paintingColorSpace() method to the color space or a paint device, or it
>> duplicates the alpha value in both:
>> in pixels and in a mask for regular RGBA devices. Despite that fact, I
>> don't object implementing this idea, because of the opportunities, that we
>> can get with the
>> structural optimizations mentioned in 1).
>>
>
> That depends on how you implement it. If done thoroughly we wouldn't have
> an RGBA device anymore: we would have an RGB + A device.


Could you, please, elaborate a bit how we will store layers in a RGB+A way?
The problem is that the basic assumption of the pigment's design (as far as
I understood it) is that the alpha channel can be accessed by the offset
inside of any pixel. So to do this separation I will have to almost rewrite
every class in it. Do you really want me to do this?

The things that will also have to be rewritten:
0) pigment
1) some parts of KisTiledDataManager
2) iterators
3) loading/saving code

The things that will need changes due to the change of the iterator's
interface

1) filters
2) convolution workers (no very difficult)
3) fill painter
4) gradient painter
5) painter and methods of paint device
6) selections (not very difficult)
7) transform worker (don't know how difficult it is)
8) paintops

It may take up to months of work.

Do I understand you right?


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120925/6c86ee19/attachment-0001.html>