koffice/krita/image/filter

[Dmitry Kazakov]

On Tue, Jan 5, 2010 at 12:48 PM, Boudewijn Rempt <boud at valdyas.org> wrote:

> On Tue, 5 Jan 2010, Dmitry Kazakov wrote:
>
> > On Tue, Jan 5, 2010 at 1:01 AM, Edward Apap <schumifer at hotmail.com>
> wrote:
> >
> > > SVN commit 1070110 by eapap:
> > >
> > > Use COMPOSITE_COPY when applying filter result
> > >
> > >
> > >  M  +1 -1      kis_filter_job.cpp
> > >
> > >
> > > --- trunk/koffice/krita/image/filter/kis_filter_job.cpp
> #1070109:1070110
> > > @@ -64,7 +64,7 @@
> > >
> > >     // blt back onto the original
> > >     KisPainter p2(m_dev);
> > > -
>  p2.setCompositeOp(m_dev->colorSpace()->compositeOp(COMPOSITE_OVER));
> > > +
>  p2.setCompositeOp(m_dev->colorSpace()->compositeOp(COMPOSITE_COPY));
> > >     p2.setSelection(m_selection);
> > >     p2.bitBlt(m_rc.topLeft(), dst, m_rc);
> > >     p2.end();
> > >
> >
> > COMPOSITE_COPY doesn't pay any attention to the selections. At least it
> used
> > to. Please check whether this patch breaks selected filter application.
>
> Was there any reason for not fixing composite copy to take the mask into
> account?
>

I don't know really. But it seems to me if we fix COMPOSITE_COPY, there will
absolutely be no difference between COMPOSITE_COPY and COMPOSITE_OVER.

Just a thought: _COPY just copies area without any knowledge of it's
content, while _OVER reads alpha() first.

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100105/8e97661e/attachment.htm