tiles & memory

[Boudewijn Rempt]

On Thursday 12 October 2006 10:03, Cyrille Berger wrote:

> not really, it's only a quarter of the time. But you know, you have to
> spend cpu cycles at some point :D

Yeah, but preferably as few as possible.

> Anyway, there is a possible optimization for symetric kernel, I might play
> with it sometime. But we still need a faster general convolution code :)

We should, perhaps, investigate how Vips works for convolution. Vips is pretty 
fast and can handle really large images.

> For 1.6, I have a possible solution, expand the API of colorspaces, and a
> convolution function that takes an array of pixels instead of an array of
> pointers of pixels. It would prevent around 80% of the memcpy, one other
> advantage is the use of consecutive memory which might boost the
> computation a little bit more, but I am not too willing to expend 1.6 API.
> (an other solution might be to keep the pointer of pointer, and to move
> them in the grid, this solution spares around 60% to 70% of the memcpy)

Let's investigate that for trunk; but I guess that doesn't obviate the need 
for making it possible to keep chunks of tiles in memory, does it?

> > > As for locking too big area, we can limit size, like preventing the
> > > user to lock in memory more tiles than the maximum numbers of allowed
> > > tiles.
> >
> > We do need to think about our API, though. Maybe add a system.exit(0) if
> > the programmer locks too large an area, so he'll know he was wrong before
> > shipping. That'll larn them!
>
> well, and if shipps without seeing that he was wrong ! Then the user
> says "krita suxx"

We did actually ship Krita 1.4 with an abort() in the code... That was really 
bad.

-- 
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/0b76c939/attachment.pgp