Mirror strokes feature

Adam C. nospam at xibo.at
Sun Oct 17 13:56:25 CEST 2010

the layout got damaged, so resending ^^

it's a quite similar idea, as david revoy's and i also thought of blender,  
while writing it. the idea of being able to set custom operations sounds  
good to me.

I'd like to add my two cents :)

o KisPainter
also i'm thinking, that it is too low level.

o KisPaintop
The code could be kept in a superclass probably. but it feels wrong to me  
to put code for mirroring in a paintop. it's rather not paintop setting.

o KisTool
Quite easy to implement, because you would only have to mirror the  
coordinates and the mask. one wouldn't have to care about paintops  
supporting it or not. i can't judge the memory and performance impact  
though. we would have some duplicated code for other tools (rect, ellipse  
etc), unless we refactor it, so that tools have a part of their ui in  

new idea:
o add it as a new type of layer or filter
- rationale:
i opened krita and thought of where i would search for such an option. it  
is a canvas thing for me, but it would be inconvenient, if
it's a setting for the whole canvas. it should be rather a layer property  
and then came the idea of implementing it as a new kind of layer or a  
- user workflow:
mark a layer and add a mirror. it would be created as a subitem for the  
layer only or a global mirror for the whole image.
- how it might work: the mirror layer has access to the paint device of  
its parent, no? so the only thing, what has to be done, is mirror it and  
composite normal. we would have to mirror the update rects of course.

i don't know, how fast and memory consuming this would be and how hard it  
is to code.
it's just an idea :)


On Sun, 17 Oct 2010 12:51:59 +0200, LukasT.dev at gmail.com
<lukast.dev at gmail.com> wrote:

> Hello,
> I talked with Cyrille on IRC about mirror strokes feature, part of the  
> 2.4
> feature list.
> The idea is inspired by Alchemy which is used on the DVD Chaos&Evolution.
> "The 'mirror' is for me the only reason why I switch to alchemy." deevad
> I want to implement it as it is hot feature for digital painters. The  
> problem
> is how to implement it.
> My idea is to mirror the output of the paint op.
> That's clear for Pixel brush. You stroke on the left side of the canvas
> and the right side has mirrored stroke.
> Some ASCII art:
> stroke  | ekorts
> is here | ereh si
> But it is complicated for smudge, deform, maybe sketch:
> Should smudge paintop smudge the right side or copy the result of  
> smudging to
> the right side? In the ideal world it could of course, but it's  
> complicated
> when you want to implement it. And it is usable that way? Do you smudge  
> in
> mirror mode? Or it is just nice to have?
> Currently in the first iteration (for 2.4) I plan to implement only  
> mirroring
> of the output and if it will be easy enough or we find some nice solution
> together, I can work on it for 2.4.
> My analysis I did so far
> Where to implement it:
> o KisPainter
> You would have to implement mirroring in every bitBlt method. Some
> paintops need to know which rects has been changed in the layer  
> (currently
> experiment paintop, but I suppose more animated paintops will be there )  
> so
> every bitBlt should return QVector<QRect>. I and Cyrille, we don't think  
> it is
> nice. I don't like when low-level features like bitBlt knows fancy  
> feature.
> Then bitBlt could be hard to optimize. Similar situation happened to  
> composite
> ops. We solve there feature if the channel is active. When we tried to
> optimize composite ops with MMX/SSE, this feature was standing in the  
> road
> AFAIR.GEGL is not doing that. That's just example why I think this kind  
> of
> features should not be on that level.
> o KisPaintop
> The only drawback I see is that the author of the paintop is responsible  
> for
> the implementation so more work for author of the paintop. There might  
> be some
> code duplication from the beginning til I find some nice pattern in the  
> code.
> Some mirroring (e.g. smudging/deforming both sides) might be complicated.
> Problem is UI, every paintop need to setup mirror axis X and mirror axis  
> Y.
> Maybe freehand tool could have the UI and setup the paintop, but then
> every paintop needs to support mirroring.
> o KisTool(Freehand)?
> Cyrille, here you go and please explain what is your idea?
> I was thinking about creating two paintops in the freehand and mirror the
> input coordinate and give some flag to paintop that it is painting in the
> vertical/horizontal mirror mode so that the mask is mirrored? Drawback  
> might
> be the performance as the paintops does not share some memory stuff that  
> are
> shared in other cases like KisPaintop place. Just my guess what Cyrille  
> might
> thought...
> == CUT HERE ==
> Brainstorm, feedback, constructive critique, creativity welcomed!
> "That's bad, don't do it" without arguments will be ignored ;)
> Mirror feature live in action at ~10:00 in the video
> http://www.youtube.com/watch?v=kGOtGDQ-K-g
> Mirroring implemented for the experimental paintop on the paintop level
> http://imagebin.ca/view/VmEHZT.html
> I will send the patch against trunk later if you are interested.
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

More information about the kimageshop mailing list