On-canvas preview of the brushes

[Cyrille Berger]

On Sunday 03 May 2009, LukasT.dev at gmail.com wrote:
> On Sunday 03 May 2009 19:18:32 Cyrille Berger wrote:
> > On Friday 01 May 2009, LukasT.dev at gmail.com wrote:
> > > There are some nice commits from Cyrille in trunk about the preview of
> > > the brush on the canvas. So far it is little buggy. When you select the
> > > Pixel Brush and select the diameter e.g. 25 and try to paint, you will
> > > get the wrong result.
> >
> > I know, I have been delaying investigating that until we decide to use
> > KisBoundary(Painter) or your equivalent code.
>
> What I need is coordinates system that I can relay on. I did detection of
> the edge pixels in my paintop. I detect the boundary of the brush and the
> results are in absolute coordinates (QPointF). I would do
> painter.paintPoint(QPointF) but before that I need to know how to translate
> my absolute coordinates I get from KisPaintDevice to the coordinates in the
> screen which will respect the zoom and resolution and related attributes
> which come into the way :)
What do you call absolute coordinates ? Image coordinate, or view coordinate ? 
If it's image coordinate, it's more than a paintPoint (since in a view a pixel 
of the image/brush outline can be represented by more or less pixels than in 
the image depending of the zoom level), I strongly suggest to have a look at 
ui/kis_boundary_painter.*

> > > I have some questions about the code as I don't understand it a bit:
> > >
> > > The code is in PaintOpSettings object.Will it be possible to change the
> > > state of the shape of the preview throught stroke painting? The way I
> > > see it now would be : add some variable to Settings Object and call
> > > setter in the paintAt? There is reference to settings object in the
> > > constructor, so paintop would have to make member with reference.
> >
> > In 1.6 brushoutline is disabled when painting. The only usefull outline
> > when painting is the one of the source of duplicating. (which probably
> > means we need to pass an enum to paintOutline(Rect) to indicate the state
> > (for now painting/notpainting) ).
>
> I think some brushes could have outline even when painting, e.g. ArtRage
> shows it all the time. It is nice feedback result but may be slow for some
> paintops. If it will be configurable, we win.
Somehow, I feel it will be slow for most paintop... Right now it's rather 
fast, but drawing a circle is way more faster than drawing a brush outline.

> > > This returns the area of KisImage that should be recomposited? If so I
> > > would propose to just return the QRectF which would represent the size
> > > of the brush and handle the pixelToDocument higher in the API as I'm
> > > really confused with it.
> >
> > No because, QPainter works with view coordinates, and I think
> > paintOutlineRect and paintOutline should work in the same coordinate
> > system. It's probably worth to have a common API for computing this
> > things, for instance in KisBrush for use by all KisBrush based paint op.
> > I don't think there is a way to make QPainter works in image coordinates
> > instead, and anyway, I don't think we want to do that, that would make
> > paintOutline rather inconsistent with every other place where we draw
> > things on the canvas.
>
> There is process that translate the coordinates and the part of it could be
> higher in API. Something like documentToView and imagePixels methods. They
> are going to be called in every paintop anyway right? You can't reinterpret
> that coordinates in different way anyway I suppose. e.g. the duplicate
> paintop uses one more outline but it is just translated, there is just easy
> relation between them.

If I get you correctly, you want a convenient function for pixelToView ? I 
suppose we can add that in KisImage that would take also take a 
KoViewConverter and do the call documenToView(pixelToDocument()).

-- 
Cyrille Berger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090504/33bd7323/attachment.htm