<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">
> > I'm not convinced that we're just having problems with dabs -- I think it's<br>
> > a more general problem, that shows up everywhere in krita where we<br>
> > manipulate paint devices.<br></div></blockquote><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">> Could you make a couple of examples? I don't get it.<br>

<br>
</div>The hairy brush doesn't create dabs, the fill tool doesn't create dabs, the gradient tool doesn't create dabs -- and they all need an alpha channel to work correctly.<br></blockquote><div><br>Hairy Paintop create a fixed paint device dab, that is then bitBlt'ed onto the device, so there is no problem with it.<br>
KisFillPainter works directly with a single byte of the pixel selection, so your solution will break it.<br>KisGradientPainter works directly with bytes of the device, that is it will work as before (so not as we want it to) if we introduce a new composite op. The problem can be easily solved by adding colorSpace->bitBlt() calls to the code of the gradient painter.<br>
<br><br>Btw, I have an idea! Why do we need a special colorspace for masks at all? Just leave it alpha and add a composite op that merges grayscale colorspace of the dab into alpha colorspace? All the users who rely on alpha channel will continue work as they used to work. The users who know about the colorspace of the dab will use the conversion indirectly.<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">
> > And there's no need to actually solve it at the node level, that's too high<br>
> > up.<br>
><br>
> I don't think this is too high up. A node reports which colorspace you<br>
> should paint *on it* with. Probably, even usual colorSpace() method is<br>
> capable of doing this, but I'm not sure it'll work. It needs thorough<br>
> investigations.<br>
<br>
</div>We don't paint on nodes, we paint on paint devices. Adding api for painting to KisNode is certainly wrong.<br></blockquote><div><br>Sure we don't paint on nodes. We paint on their paint devices. But the nodes tell us *how* to paint on their paint devices. Just look at the KisPaintLayer::channelLockFlags(). Do you think it is wrong as well? Should we delete this code then? ;)<br>
I think such hints for tools are fine (except for LSP problem of channelLockFlags(), but this is a different issue).<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;">


> As I said the api of the KisPaintDevice shouldn't (and mustn't) be changed.<br><div class="im">
<br>
</div>Sorry, then your solution will not work. KisNode is the wrong place, since we do not paint on nodes.<br></blockquote><div><br>Commented above.<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, I don't think that KisSelection is a proper place for doing this.<br>
<br>
</div>Why not? That is the interface between things to paint on (the mask's paint device) and the selection itself (the selected bytes). It's the only point where the two assumptions Krita is built on come together: painting needs an alpha channel, masking needs a single byte per pixel.<br>
</blockquote><div><br>1) It triples (in the best case doubles) memory usage.<br>2) It makes us call update projection regularily, that takes time.<br>3) It makes us work directly with bytes outside pigment, that is a wrong thing.<br>
4) It throws away all the device sharing optimizations we have in KisSelection.<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;">

<div class="im">
> As I<br>
> And I don't even speak about the ability to<br>
> use 8/16 bit selection masks in the future.<br></div><br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Well, that's a lot easier to do if everything is contained inside KisSelection. Though I don't think we'll ever do 16 bit selections, no user has ever asked for it.<br>
</blockquote><div><br>I think they've never asked about it, because it is impossible now to paint semi-transparent masks. So they cannot see granularity of the mask at all.<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;">

<div class="im">
> And triple memory usage is hardly acceptable as well.<br>

</div>That is the only big problem I see. But given that this is a critical bug for the 2.4 release, I think it could be acceptable. There is no other way to fix the problem.<br></blockquote><div><br>The problem is, there is no way to solve memory problem within the confines of your design at all. In your solution there is just no way to avoid doubling of memory. It is not a problem of a particular implementation. It's just a problem of the design itself. So to fix this issue in the future (say, after the release) we'll have to revert all this work and do it again from the very beginning. Why do the work twice? Our selections are not very fast currently, why making them slower and more hungry while we have another way of doing things which is faster and doesn't double memory consumption?<br>
<br><br>Ok, just to be more objective in our conversation, let's fill the requirements for the system we want to get. What do we actually need?<br><br>1) We need to be able to paint with a brush with transparency onto selections, that is "with grayscale brush of any form" onto a selection. Selectedness is controlled by gray channel, alpha channel of the mask is just used for forming a shape of the brush.<br>
2) Selection (at least their projections) should be single-channeled, because pigment uses only 1 channel for transparency.<br>3) Some of the tools (like KisFillPainter) work directly with the byte of pixel selection, so such tools should be dealt with (fixed, if needed) gracefully.<br>
4) We shouldn't double the memory consumption of selection, when it is possible to avoid this. No additional iterations through the selection as well, because it takes time on large images.<br>5) All the tools (esp. Gradient and Fill) should take global selection into account when painting on a mask. Otherwise there is no point in using them.<br>
<br><br>Are there any other requirements I forgot about?<br><br>Could you answer the following questions:<br>1) How does you design fits them?<br>2) Is it possible to fit all the requirements in the future (on the next iteration of your work, that is after the release)?<br>
<br></div></div><br>-- <br>Dmitry Kazakov<br>