On-canvas preview of the brushes

[Cyrille Berger]

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.

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

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

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


-- 
Cyrille Berger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20090503/663c88e5/attachment.htm