ET has discovered problems during implementation, he already uses wetness, but it's probably not calculated the right way. They degenerates too fast, wetness goes to the maximum, when drawing. So the range is too small. The problem might because of too much overlays (7 by layer, that mean a total of 14). Solutions:
But BR wants to be able to copy one overlay from on an other. But as the range wasn't enought it's probably required to use float instead of bytes.
Visualization of wetness:
The second big problem, difference between color that can be changed, and color that can not be changed (dried color). Baxter has two layers, wetdream (or the based paper) proposes that when you start painting on a dry layer, then it starts to create a new layer.
Different types of materials:
Dry paint is paint that nobody can't paint anymore. BR proposed the group layer to store total wetness and the dry paint, but he decided that it's not a good idea. Second idea is to put the dry paint on a separate paint layer inside the current layer.
BC says that, if on a group layer you have a wet layer (layer 1), then a normal layer (layer 2) then a wet layer (layer 3), if the dry paint is moved in the group layer, the composition would be wrong if dry paint "by-pass" "layer 2".
ET proposed to move the overlay from the paintdevice to the layer, but BR wanted to extend the iterator to support overlay like selectness, but it's a lot of work, and it wouldn't be faster. But BR thinks that ET is right and that we can move it back.
Three paint devices in a layer : completely dry, water projection. ET proposed to have more layer, a new wet layer would be created when a layer becomes dry. In fact it's based on a pixel, when a pixel becomes dry, it is moved to a bottom layer, and on the wet layer the color is erased. But if on the dry layer there is allready a dry paint, then creates a new dry layer.
We have a choice, when using a normal paint color:
Solution might be to have the layer (dry and wet) appearing in the layerbox, then the user would select which layer (wet or dry) he selects for filtering or "normal" painting.
There are two colors, one for mixing and one which is the result. When you mix green with red, you get orange which is what you want, but on the brush you still get something green. With HSV, if you mix red and blue, you obtain cyan and not white.
difference between monodirectional / bidirectional:
Use CMYK or a spectral wavelength colorspace !
Should the mixer use the same colorspace as the current layer or allways the same colorspace ? Question, which color to select ? BR proposes to choose the color at the hotspot of the brush. One other user option !
Docker: out ! Validates what on the wiki.
The tiled data manager would be replace by multiple data manager (for instance one for the TIFF, PNG, JPEG those data manager would read directly from the files).
Solution to the swapping, loading from swap file, per thread storage, but there is a problem when thread dies. Multiple thread accessing a single file, a writting thread would "lock" the area on which is writting.
Add an age field to the tiles instead of a list of tiles that can be swapped. That way for each access the tile is time stamped, and then background thread swap the oldest tile.
Pyramids and filter that acts on more than one pixel. Pyramids out of the paint device ? Pyramids only as a zoom cache for final display ?
Filtering on image, creates a pyramid, select a level, and display it. Problems is when to create the pyramid, or allways have the pyramid ?
Pyramids only needs a third of more memory. You just need to add this to the qpainter canvas ? Pyramids at tile level ? It makes it easier to compute the pyramid, and you can have optimization for the composition level.
The big krita lock is going away, time stamps might come in. Display pyramid is going to be at tiled level.or at qimage. BR says that it should be done at qimage level, because it's what we display. Finishing the QImage context class. Should we leave it to linux to swap or not ? Different swap tile backend, one which could swap tiles, and one which could swap QImages. Swapping compressed tiles is problematic because we don't know anymore the size of a tile. But we could store the compressed the tiles with all the same size even if we don't use some bytes. BR is afraid that adding pyramid at the tile level would make it more complicated. BC has to write a mail to list describing exactly what his ideas are.
The problem is, the current flake design in krita doesn't work. We have a Krita image, we organize our layer stacks (image knows about group layer which knows about sibbling layers and paint layers know about mask effect etc...). The problem is a lot of copy/paste of code. But a layer is a layer but a mask is a mask. The hierarchy of layers couldn't use the shape layer, because that would make krita/image depends on flake (which is apparently is a problem because of QPainter use in KoShape). The interview use the layer hierarchy and not the shape hierarchy, which prevents the use of the layer box in other ko application and raises various problems.
There is a need for a common class for layer, paint, overlay, mask.
Each gui actions would emit a signal with the recorded action information.