New idea about Grayscale Selections problem

[Sven Langkamp]

On Sat, Feb 9, 2013 at 9:33 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:
> Hi!
>
> I was thinking about this problem in the background... and I guess I have a
> solution for this.
>
> Last time I suggested adding a method to the KisPaintDevice class, which
> would return a colorspace for the painting, something like that:
>
> const KoColorSpace* KisPaintDevice::colorSpace() const;
> const KoColorSpace* KisPaintDevice::paintingColorSpace() const;
>
> The former one would return a colorspace for a data stored in the device and
> the latter one would return a colorspace, which should be used by the tools.
>
> Boud objected to this solution, and, actually, I can understand that,
> because it is not obvious, which colorspace one should use in which
> circumstances.
>
> While working on the dab caching solution (KisDabCache class), I got an idea
> how to overcome this trouble. What if we change the requirements for the
> tools a bit? What if we declare that the painting tools do not work with the
> device, but work with the dab only; and that the management of dabs should
> be done not by the tools, but by the paint device instead?
>
> This would lead to the following design:
>
> 1) Generally, the tools would not create the dabs themselves.
>
> 2) The paint device would have two new methods:
>
> KisPaintDeviceSP KisPaintDevice::createDab() const;
> KisFixedPaintDeviceSP KisPaintDevice::createFixedDab() const;
>
> These methods would be used by the brush-based tools to craete a dab for
> themselves. After creation of a dab, they would not use the device's
> colorSpace() method, but would use the dab's colorSpace() method instead.
> For most of the brush-based tools there will be only few changes needed,
> because the management of the dabs s now performed by a single KisDabCache
> class for them. The rest of the brushes do not use dab cache, because they
> work with not-fixed paint devices. They create the dabs themselves.
> Obviously, the change of the way of dabs creation will not be too difficult
> ;)
>
> 3) The tools that do not work with dabs, like Filter Brush, will work
> directly with the paint device in its native colorspace. But they do not
> need anything more.
>
> This approach kills two birds with one stone: it allows the tools to paint
> in the colorspace that is different form the native device's colorspace and
> at the same time it does not create a mess by introducing the second
> colorspace property for the paint device.
>
> What do you think about such approach?

This doesn't fix the problem as it's not a problem at dab level. Dab
always need a alpha channel, otherwise you just get square blobs.
There is also Indirect painting which wouldn't be covered by that.
Other tools would still have the problem like the fill and gradient
tool.

I think the only way to solve this is that the tool will get a
gray+alpha paint device. I more and more favor that we switch the
pixel selection colospace to that. It's the only way to solve that for
all tools without messing with composite ops.