tiles & memory

[Boudewijn Rempt]

On Wednesday 11 October 2006 23:39, Bart Coppens wrote:
> 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).

No, I don't think so, concurrent access to different tiles in the same 
paint-device, yes. But locking on pixel level is going to be way too 
expensive. Maybe we need something to align the boundaries of the threads' 
regions of interest with tile boundaries, something like

QVector<QRect> KisPaintDevice::getOptimalRects(QRect rc, int numberOfRects)?

Then the filter threader can parcel out the rects to the processing threads.
 
one writer, many readers concurrency would be nice to have, but is perhaps 
very hard to do in an efficient way. For the filters that need a fringe (like 
1/2 the convolution kernel for conv. filters), we'd need to make the optimal 
rects the required number of pixels wider.

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

We must find a way to limit pixel copying. My first idea was to copy the data 
into tempory scanlines, like Gimp and Mosfet Paint do. It would copy the same 
amount of memory, but with fewer calls. But it would take a lot of memory 
anyway. I wonder if there's more literature on this subject that could help 
us. And, as a rude poster mentioned in a comment on my blog, we need to think 
of using the processor cache in the best possible way, too.

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

It's way better than manual unlock, so we need something like this.

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

Of course, but we don't want to allow users to shoot themselves in the foot. 
And the default is much too low. Relatedly: in the config widgets, the 
swappiness slider: is left more swapping or right more swapping? We should 
add some legend there.
-- 
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: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20061012/b2928461/attachment.pgp