On-canvas preview of the brushes

[LukasT.dev@gmail.com]

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 :)

>
> > 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.

>
> > 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.

>
> > You create QRectF of the brush, which is transformed into pixelToDocument
> > and the result is then translated to the position of the centre of the
> > brush? Is it right?
>
> Yup.
>
> > QRectF KisBrushOpSettings::paintOutlineRect(const QPointF& pos,
> > KisImageSP image) const
> > {
> > ...
> > return image->
> > pixelToDocument(
> > QRect(0,0, brush->width(), brush->height() )
> >  ).translated( pos - hotSpot + QPoint(1,1)
> > );
> > }
> >
> > Here is drawOutline, which draws outline. I would again propose just to
> > paint on the pos which would be transformed before this method is called
> > higher in the API. So that you don't have to handle the transformation
> > process in the paintop as it leads to code duplication and mistakes.
>
> I wonder about that, since the duplicate op would need the aboslute
> position as well (but we might do that and still pass the position if a
> paintop need to draw something with absolute coordinated).
>
> > Let me guess what this is doing:
> > documentToView convert from pt to pixels. Why do you need it?
> > pixelToDocument transform the translated QRect area of the brush and
> > result is converted from pt to pixels?
>
> The documentation is not clear but I would have think the function name
> would be descriptive enough :/ In Krita there are two different "types" of
> pixels, the image pixel (in which the brush size is expressed), the
> view/widget/UI pixels (which correspond to the zoom level). For instance at
> zoom level 200%, one pixel of brush is shown as two pixels in view.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090503/ff67632e/attachment-0001.htm