tiles & memory

[Bart Coppens]

On Wednesday 11 October 2006 23:13, Boudewijn Rempt wrote:
> bool lockRegionInMemory(QRect)
> bool unlockRegion(QRect)
> both, of course, thoroughly mutexed so we're prepared for multi-threading.
Of course, we'll need to mutex a lot more stuff, afaik, to be truly ready for 
this. (At least, concurrent access to the same tile, but I'm not sure we 
really want that).

> The idea is that the datamanager would keep the region in memory so, for
> instance, the convolution painter can work with pointers instead of
> laboriously copying the memory.
I'm obviously not jumping with joy. Not only at the idea of exposing in-memory 
to the API, but also not at the idea that plugins will be able to arbitrarily 
ignore the user's wishes (which they already can, but in a much more indirect 
way). I fear that this will be abused and make stuff slower in the end, but 
that's just a pessimistic guess. (Guess: code for filters that will just try 
to lock their entire m_rc, or so. And then a user will try that filter on his 
spiffy 5000x3000 image and *poof* Krita will load the entire image in 
memory.)
But at the very least, let it use RAII, like the Iterators already do. Making 
the programmer remind himself to unlock the region every time he leaves the 
function (which can be in other places than the obvious last line of it), 
_will_ cause problems with code not unlocking stuff. I propose something like 
KisRegionLock, or so. you acquire it through lockRegionInMemory, and it 
releases itself on destruction, or on manual release. Or so. But still, I'm 
not sure this is the way to go.

> Relatedly: let's set the minimum number of tiles
> (64x64xchannelsxchanneldepth bytes) to at least 1000, and let's not allow
> the user to specify a value lower than that. Krita is an image editor, not
> a postage stamp editor!
Sure, but setting it to extremely low values is useful to debug stuff ;-) It 
exposes many subtle bugs a lot more rapidly. Bugs that would otherwise 
continue being there, lurking, until it can randomly attack a wary user of a 
stable Krita release. Which we obviously won't be able to reproduce, because 
it's a lot more random with regular values. Just to say that it has its 
advantages, even though not for the user :-)

Bart