PaintDevice/Layer/Mask/Selection/Overlay

[Schleimer, Ben]

Hey Boud,

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

Um, if these properties are per-pixel, they should probably be a channel in the KisPaintDevice.
If they are physical properties, overlay may not be the best name for them...

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

This sounds like the job of the projection KisPaintDevice. I understand if KisPaintEngine isn't
ready yet but you probably don't want to expose the KisShapeLayer::canvas in the interface as it
is an implementation detail.

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

This is an implementation detail and shouldn't be exposed in the interface.

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

So the global selection needs to be displayed somewhere...

Keep up the good work,
Ben