I’m writing a photoshop-like program for a mobile device and I want to support the use of layers. At most, I can store about 7 bitmaps in memory at a time. I’m trying to see if I can come up with a way of supporting lots of layers (e.g. 10 or 20) while not using much memory.
My current idea is:
- Use one bitmap as the active layer that the user can currently paint on and manipulate.
- Use one bitmap that stores a flattened version of all the layers below the active layer.
- Use one bitmap that stores a flattened version of all the layers above the active layer.
When a layer is not the active layer, I can write it to disk and remove it from memory. When the user switches active layer, I then retrieve the layer from disk and recreate the flattened images.
This idea appears sound if each layer only has opacity settings, but I don’t think it will work if layers can have different blending modes like screen and multiply. The flattened bottom layers would work fine but it seems as if I would need to rerender all the top layers again if one of these used a blend mode and the active layer was changed.
What approach can I use? I’ve seen various paint programs supporting 100 and more layers so there must be some trick to it.
Well, I think you’ve already got a reasonable approach for the case where the layers just have simple opacity, but I can see the problem if they had different blending modes.
One suggestion could be to chop the image into sub-blocks, e.g. 32×32 in size and only re-blend the ones where something has changed. You could have a sort of cache of sub-blocks in main memory so that if the user is editing only a small region, you’ve have the data you needed most of the time. It would be complex, but you could still keep contiguous layers that only need opacity blending to potentially improve performance.
I seem to remember that Photoshop at least used to do this – they might have had a hierarchy, but the image was split blocks.