Painting on selections and selection masks

[Dmitry Kazakov]

> > 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? ;)
>
> Completely different situation. Enabling/disabling channels is a gui
> function that doesn't change the colorspace.
> 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.


It returns not "colorspace+alpha", but "colorspace for painting". It's
completely different.


> > 1) It triples (in the best case doubles) memory usage.
>
> 2) It makes us call update projection regularily, that takes time.
>
> 4) It throws away all the device sharing optimizations we have in
> KisSelection.
>

> From a design pov, irrelevant; we already have a projection mechanism
> there.
>

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.


> > 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?
> >
> > 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.
>
> 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.
>

Ok, agree.


>
> > 2) Selection (at least their projections) should be single-channeled,
> > because pigment uses only 1 channel for transparency.
> > 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.
> > 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.
> > 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.
> >
> >
> > Are there any other requirements I forgot about?
>
> Yes: needs to be done in time for the 2.4 release without breaking all of
> Krita.
> 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.
>

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.

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.

[1] - e.g. KisFillPainter

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20111030/4e77927a/attachment.html>