<br><br><div class="gmail_quote">On Tue, Sep 25, 2012 at 4:30 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think you need to take a step back from the proposal you came up with a year ago and take a look at the big picture, because since then we have learned a number of things.<br>
<br>
The problem itself should be redefined as "we need to be able to handle<br>
colorspaces without an alpha channel", not we need to figure out a trick to make painting on selections work.<br></blockquote><div><br>Wait, as far as I remember we were talking exactly about "how to make grayscale selections work".<br>
<br>If you want to change the topic of the project, please express this more clearly, than just putting veto on the idea and suggesting intermediate-projections-in-kis-selection solution.<br><br>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>


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 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 will be optimized here.<br>3) We will still have to use something like KisPaintDevice::paintingColorSpace() or KoColorSpace::paintingColorSpace() to get a colorspace for the other components of the pixel *or* store the alpha mask twice: both in pixels and in a separate mask.<br>
4) The KisToolFill and KisToolGradient will need changes as well.<br><br>I dropped this idea then because I though it would demand too much changes and take too much time.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

* Limiting the brush mask to 8 bits integer precision makes painting on higher bit depth colorspace paint devices lose precision.<br></blockquote><div><br>This is a completely different problem and can be solved separately after we implement any of the suggested ideas.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

If we take the alpha channel out of band, then pass the brush mask as an alpha channel as a separate parameter to KoColorSpace::bitBlt, we'll actually have solved the problem in a generic way, without adding hacks to KisPaintDevice.<br>
</blockquote><div><br>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).<br>
<br>Ok, if you want I can think about this idea. But its implementation will take quite much time.<br><br></div><br></div><br>-- <br>Dmitry Kazakov<br>