<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">
> Sure we don't paint on nodes. We paint on their paint devices. But the nodes<br>
> tell us *how* to paint on their paint devices. Just look at the<br>
> KisPaintLayer::channelLockFlags(). Do you think it is wrong as well? Should<br>
> we delete this code then? ;)<br>
<br>
</div>Completely different situation. Enabling/disabling channels is a gui function that doesn't change the colorspace.<br>

Having a special function on KisNode just to get a colorspace+alpha if the node's paint device has a colorspace-alpha is not good api. </blockquote><div><br>It returns not "colorspace+alpha", but "colorspace for painting". It's completely different.<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">
> 1) It triples (in the best case doubles) memory usage. </div></blockquote><div></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">
> 2) It makes us call update projection regularily, that takes time. </div></blockquote><div></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">> 4) It throws away all the device sharing optimizations we have in KisSelection.<br>
</div></blockquote><div></div><div></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">
<br>
</div>From a design pov, irrelevant; we already have a projection mechanism there.<br></blockquote><div><br>It is relevant, because in the common case there is no projection mechanism used so no memory duplication happens. The devices are shared between pixel selection and the projection. The projection appears in the only case when we have both vector and pixel selections on a canvas, that is a rare case.<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">
> Ok, just to be more objective in our conversation, let's fill the<br>
> 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<br>
> selections, that is "with grayscale brush of any form" onto a selection.<br>
> Selectedness is controlled by gray channel, alpha channel of the mask is<br>
> just used for forming a shape of the brush.<br>
<br>
</div>No: we need to be able to use any pixel manipulation part of Krita, from brushes to filters, on the global selection or any mask.<br></blockquote><div><br>Ok, agree.<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"><br>
> 2) Selection (at least their projections) should be single-channeled,<br>
> because pigment uses only 1 channel for transparency.<br>
> 3) Some of the tools (like KisFillPainter) work directly with the byte of<br>
> pixel selection, so such tools should be dealt with (fixed, if needed)<br>
> gracefully.<br>
> 4) We shouldn't double the memory consumption of selection, when it is<br>
> possible to avoid this. No additional iterations through the selection as<br>
> well, because it takes time on large images.<br>
> 5) All the tools (esp. Gradient and Fill) should take global selection into<br>
> 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>
</div>Yes: needs to be done in time for the 2.4 release without breaking all of Krita.<br>

Krita currently is, from the canvas to the filters, from the tools to the projection update full of unfinished refactorings. We are not going to do another big refactoring between now and RC1.<br></blockquote><div><br>I'm sorry for the question, but why are we trying to implement a *feature request* after the feature freeze in a month to the release using a hack that may break some tools [1] instead of finishing all these "unfinished refactorings"? If we can't do this fast and efficient without multi-colorspace composite ops (or any other non-hacky solution), why don't we want to fix other inconsistencies we have in Krita instead? We have loads of them: global selections vs actions like crop and resize, vector and pixel selections used simultaneously, action recording vs global actions and new tools, fill tool and scaling being incredibly slow. Krita has loads of features, but only a few of them are really usable. Just try to record a crop of the image. And this is not actually a bug. This is a design feature/flaw (depending on how you look at it). Because we need to have a copy of all the tools' hierarchy and duplicate their code there, in the action recording part, to be able to record Krita actions consistently. So currently, some of the tools have a corresponding recording part, some don't. So some tools are recorded, and some aren't.<br>
<br>I think, now we should stop adding new features and especially hacks which add features and start making a consistent system of what we do already have. We have loads of old code that works on a limited range of input values only. Such inconsistent system cannot attract either new users or new developers. Our future is not bright unless we make a stable and consistent thing from what we have now.<br>
<br>[1] - e.g. KisFillPainter <br clear="all"></div></div><br>-- <br>Dmitry Kazakov<br>