Painting on selections and selection masks

[Boudewijn Rempt]

On Sunday 30 October 2011 Oct, Dmitry Kazakov wrote:
> > > 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.

No, it is not. Sorry, but I see this in a completely different light. I definitely and absolutely do not want to add generic api to get a completely different colorspace from the one the device actually uses to solve one problem, namely painting on selections.

We don't need that generic ability.

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

There is a projection mechanism already. It's not used right now in the most common case, but that is not relevant: the mechanism is there.
> 
> 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"?

Because it is a two-year old critical bug, not a feature request.

Users need this to work, and they have told us so years ago. We have tried to fix it in various ways, not realizing that Krita's design means that none of those solutions can possibly work. The bug has been assigned to you, it was in fact the most important part of the work on selections, but it didn't work out, Sven has worked on it, but it didn't work out, I have worked on it. It's not something we've just started work on, and it is something that makes life hard for users.

It needs to be fixed in time for the release, and I have not seen any other proposal that will a) work and b) not cause lots changes all over Krita and pigment.

I prefer a local solution that might be inefficient to another big refactoring.

We currently have four critical bugs that will prevent Krita from being released:

250146 	cri dmula73 at gmail.com REOP Ctrl-"+" does wrong centering of the image
273357 	cri dimula73 at gmail.com REOP The canvas is not scrolled to the cropped area after the crop
217292 	cri boud at valdyas.org ASSI Ability to paint transparency masks
262324 	cri lukast.dev at gmail.com NEW krita produces artefacts when upscaling 

They should have top priority.

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

There is no "instead" -- we have 113 bugs right now, and they need to be fixed. And as maintainer, I'm very unhappy currently since I see no progress at all. Many of those bugs are direct results of big refactorings (recomposition, strokes framework, selection handling, canvas refactoring, action recording) that never were fully finished.

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

This is not a feature. It is a critical bug. For the rest, yes, we need to get off our collective butts and start fixing those bugs.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl