<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">
> > colorspaces can convert the pixels from another colorspace to their own<br>
> > before doing composition, but for painting on masks that's not currently<br>
> > useful since we generate dabs in the target colorspace anyway.<br>
> ><br>
><br>
> Well, the colorspace of a dab is really not a problem, i guess. A node can<br>
> have both paintDevice() and dabColorSpace() methods. And tools can use the<br>
> latter one to create a dab of a proper colorspace.<br>
<br>
</div>I'm not convinced that we're just having problems with dabs -- I think it's a more general problem, that shows up everywhere in krita where we manipulate paint devices.<br></blockquote><div><br>Could you make a couple of examples? I don't get it. <br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

And there's no need to actually solve it at the node level, that's too high up.</blockquote><div><br>I don't think this is too high up. A node reports which colorspace you 
should paint *on it* with. Probably, even usual colorSpace() method is 
capable of doing this, but I'm not sure it'll work. It needs thorough 
investigations.<br> 
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> And even on the paint device, there's no need to add a separate api to get a colorspace that's useful for dabs, </blockquote>
<div><br>I agree that the dab's code has nothing in common with paint device's api. This is a trait of a node. A node controls original(), projection(), paintDevice() and a paintingColorSpace(). The latter one is a colorspace that is used for painting on a paint device. I think it looks quite sane, isn't it?<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">if we only do something special-cased for dabs, then it needs to go into that specific part of the code.<br>
</blockquote><div><br>The good think about node->paintingColorSpace() that it is not a special case. This is a common case that can (and should) be used by everyone. No hacks, no workarounds needed.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


Then we can check whether the colorspace of the device has an alpha channel, and if not, use one with an alpha channel, which then gets converted during bitBlt.<br>

But as I said, I tried that, and it was messy and didn't solve the problem generally.<br></blockquote><div><br>Yes, I agree that checking for the presence of the alpha channel is not a good solution.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">> Well, if we decide to have different colorspaces for a dab and a paint<br>
> device then we will avoid this limitation.<br>
<br>
</div>But only for painting, only for this case. I do not think it's a good idea to expand the api of KisPaintDevice with something special-cased for dab creation.<br></blockquote><div><br>As I said the api of the KisPaintDevice shouldn't (and mustn't) be changed.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
>  I'm sure we shouldn't hurry with such decisions. Especially, after we have<br>
> released several betas.<br>
<br>
</div>No -- but not being able to properly paint on selections and masks is a critical bug, which is why I have tried to find a minimally invasive way to make it possible, mostly contained in KisSelection. Unfortunately it means we triple memory usage for selections, so we have to think whether that's worth it.<br>
</blockquote><div><br>Well, I don't think that KisSelection is a proper place for doing this. As I can see in your patches, you copy bytes from one colorspace to the other inside KisSelection. So you do the conversion actually. Isn't it exactly what pigment is supposed to do? And I don't even speak about the ability to use 8/16 bit selection masks in the future.<br>
<br>And triple memory usage is hardly acceptable as well.<br></div></div><br>-- <br>Dmitry Kazakov<br>