PaintDevice/Layer/Mask/Selection/Overlay

[Boudewijn Rempt]

On Tuesday 15 May 2007, Schleimer, Ben wrote:
> Hi Boud, just a few quick comments on the design:
> > Paint Layer
> >
> > paint device -> overlays -> effect masks -> projection
>
> Whats the difference between overlays and effect masks? It might be worth
> clarifying...

A painterly overlay is a mask that is not associated with a filter but 
specialized to represent a particular physical property like canvas height, 
canvas absorbency, paint wetness, paint stickiness etc.  It may modify the 
look of the paint for visualisation purposes. When a physics filter runs 
modifies the distribution of color in a particular way. When a brush is 
applied to the paint layer, the brush may take the overlays into account when 
depositing color (or wetness etc on the overlays). It is Emanuele's gsoc 
project to implement this.

> > Group Layer
> >
> > layers -> composition -> projection 1 -> effect masks -> projection 2
>
> Why do you need two projections? This might be pre-mature optimization.

I've wondered about that, too, but couldn't reach a firm conclusion.

> > KisLayer {
> >	KisPaintDeviceSP projection
> >	QList<KisMask> effectMasks
> > }
>
> According to this:
> http://wiki.koffice.org/index.php?title=Krita/SelectionsMasks, effect masks
> are single channel paint devices+a KisFilter. Or is that what KisMask is
> supposed to be?

Well, actually, the class in question is KisEffectMask (which 
is ::KisMask::KisPaintDevice).

> > KisShapeLayer::KisLayer {
> >	KisPaintDevice canvas
> >	KoShapeManager shapeManager
> > }
>
> Why does the KisShapeLayer need a canvas? I think it would be much simpler
> to have it render just shapes and then have the projecting process add
> canvas via paint layers underneth the shape layer.

Because shapes need to be rendered onto a canvas (KoCanvasBase implemention). 
The canvas renders onto a QImage (because shapes render using a QPainter and 
while KisPaintDevice _is_ a QPaintDevice our KisPaintEngine::QPaintEngine 
isn't (yet) good enough). The QImage is rendered to a KisPaintDevice which is 
composited in the stack. It's this KisPaintDevice I'm calling a canvas above. 
We can either keep the QImage around and convert it every time we need to 
composite or keep the converted KisPaintDevice around. The latter is 
preferable because it is a tiled data structure with a swap file, QImage is 
just a big linear in-memory buffer. Besides, it saves time when 
recompositing.


> > KisAdjustmentLayer::KisLayer {
> > 	KisMaskSP mask
> > 	KisFilter filter
> > }
>
> You could also just make the KisAdjustmentLayer's mask+filter be an
> effectmask. It seems to be the same...

Not quite: adjustment layers could be replaced by a group layer containing the 
layers in the stack underneath the adjustment layer plus an effect mask. We 
discussed that but concluded that it would be simpler for the user to keep 
adjustment layers. It keeps the layer hierarchy flatter. And... See below for 
where the real difference (will) come in.
 
> > Two complications:
> >
> > * KisAdjustmentLayer shouldn't have effect masks, that's silly.
>
> Um, it's probably not worth limiting this possibility useless it interferes
> with using adjustment layers. It could be useful for some people...

This morning I discovered why we'd want to have effect masks on adjustment 
layers -- the effect masks may modify the mask of the adjustment layer (like 
doing a sharpen, blur or edge detection) and that could be useful. Since we 
don't nest effect masks, this makes adjustment layers a lot more different 
from the group+effect mask equivalent described above.

> > * The optimization where if there's only one layer and no effect masks,
> > that layer is also the projection of the owning group layer should be
> > kept
>
> Premature optimization. If there are no masks, then projection will be
> O(1)

Not quite: if we don't optimize, for every recomposition the layer's paint 
device would be copied to the group's projection. We noticed quite a speedup 
in krita 1.6 (or was it 1.5?) when we added this optimization.

> > for painting we should be able to call KisLayer::canvas() -- which
> > returns the mask in the case of an adj. layer, the canvas in the case of
> > a paint layer and nothing in the case of other layer types.
>
> This is probably bad generalization of a single method. If you want to
> provide an accessor to the paint canvas of the KisPaintLayer, then have a
> KisPaintLayer::canvas method. If you want to access the adjustment layers
> effectmask, then have a KisAdjustmentLayer::effectMask(). I think its bad
> to have a method return different items depending on the class. It'll cause
> bugs later on.

Ok. I'll keep that in mind when I work on it. Sounds good.

> > Selections:
> >
> > Right now the selection is part of KisPaintDevice. We have agreed on
> > having more than one selection type per layer: namely one that determines
> > reading and one that determines writing, and one that determines both.
> > That means three KisSelectionSP's on the paint device, unless we go a
> > KisSelection with three channels, of course.
>
> Why do we need a mask for both? Why not just one for reading and one for
> writing?

Yes, that's right. I'll do that -- make KisSelection have two masks, one read, 
one write.

> Hope this helps your design work. I love the progress...


> PS. I wonder if per-layer selections is wise from the UI POV. How is the
> user going to know if he's working with the global selection or layer
> selection? Is the global selection going to be overridden by the local
> selection whether the user switches layers? How/why would the user save the
> global selection to the layer?

We'll show the selections in the layer box; if present, the global and layer 
selection will be merged when working on the layer. The global selection can 
be drag & dropped to a layer (or moved/copied using a menu action, of 
course). 

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20070515/50dde6bb/attachment.pgp