[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Painting on selections and selection masks
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2011-10-30 13:11:07
Message-ID: CAEkBSfVu3OErfh4gPaY0xhB=xS=58Sn7Hw6B7DQh90QqSSsx4Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> > 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
[Attachment #5 (text/html)]
<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>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic