Painting on selections and selection masks

[Dmitry Kazakov]

> > > colorspaces can convert the pixels from another colorspace to their own
> > > before doing composition, but for painting on masks that's not
> currently
> > > useful since we generate dabs in the target colorspace anyway.
> > >
> >
> > Well, the colorspace of a dab is really not a problem, i guess. A node
> can
> > have both paintDevice() and dabColorSpace() methods. And tools can use
> the
> > latter one to create a dab of a proper colorspace.
>
> I'm not convinced that we're just having problems with dabs -- I think it's
> a more general problem, that shows up everywhere in krita where we
> manipulate paint devices.
>

Could you make a couple of examples? I don't get it.



> And there's no need to actually solve it at the node level, that's too high
> up.


I don't think this is too high up. A node reports which colorspace you
should paint *on it* with. Probably, even usual colorSpace() method is
capable of doing this, but I'm not sure it'll work. It needs thorough
investigations.


And even on the paint device, there's no need to add a separate api to get a
> colorspace that's useful for dabs,


I agree that the dab's code has nothing in common with paint device's api.
This is a trait of a node. A node controls original(), projection(),
paintDevice() and a paintingColorSpace(). The latter one is a colorspace
that is used for painting on a paint device. I think it looks quite sane,
isn't it?



> if we only do something special-cased for dabs, then it needs to go into
> that specific part of the code.
>

The good think about node->paintingColorSpace() that it is not a special
case. This is a common case that can (and should) be used by everyone. No
hacks, no workarounds needed.



> Then we can check whether the colorspace of the device has an alpha
> channel, and if not, use one with an alpha channel, which then gets
> converted during bitBlt.
> But as I said, I tried that, and it was messy and didn't solve the problem
> generally.
>

Yes, I agree that checking for the presence of the alpha channel is not a
good solution.



> > Well, if we decide to have different colorspaces for a dab and a paint
> > device then we will avoid this limitation.
>
> But only for painting, only for this case. I do not think it's a good idea
> to expand the api of KisPaintDevice with something special-cased for dab
> creation.
>

As I said the api of the KisPaintDevice shouldn't (and mustn't) be changed.



>  >  I'm sure we shouldn't hurry with such decisions. Especially, after we
> have
> > released several betas.
>
> No -- but not being able to properly paint on selections and masks is a
> critical bug, which is why I have tried to find a minimally invasive way to
> make it possible, mostly contained in KisSelection. Unfortunately it means
> we triple memory usage for selections, so we have to think whether that's
> worth it.
>

Well, I don't think that KisSelection is a proper place for doing this. As I
can see in your patches, you copy bytes from one colorspace to the other
inside KisSelection. So you do the conversion actually. Isn't it exactly
what pigment is supposed to do? And I don't even speak about the ability to
use 8/16 bit selection masks in the future.

And triple memory usage is hardly acceptable as well.

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