<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">If we want to mix this work with optimization, then we should call it a bit differently: "we need to be able to handle<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
colorspaces with a *separate* alpha channel".<br>
<br>
On Sunday I thought about an idea of passing the separate alpha to bitBlt as well. Here are the conclusions which I came to:<br>
<br>
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<br>
efficiently. I can't tell how much speed it will give.<br>
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<br>
will be optimized here.<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br>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.<br>
  <br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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:<br>
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<br>
structural optimizations mentioned in 1).<br>
</blockquote>
<br></div>
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.</blockquote><div><br>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?<br>
<br>The things that will also have to be  rewritten:<br>0) pigment<br>1) some parts of KisTiledDataManager<br>2) iterators<br>3) loading/saving code<br><br>The things that will need changes due to the change of the iterator's interface<br>
<br>1) filters<br>2) convolution workers (no very difficult)<br>3) fill painter<br>4) gradient painter<br>5) painter and methods of paint device<br>6) selections (not very difficult)<br>7) transform worker (don't know how difficult it is)<br>
8) paintops<br><br>It may take up to months of work.<br><br>Do I understand you right?<br><br><br></div></div>-- <br>Dmitry Kazakov<br>