tiles & memory

[Cyrille Berger]

On Thursday 12 October 2006 08:11, Boudewijn Rempt wrote:
> On Wednesday 11 October 2006 23:54, Cyrille Berger wrote:
> > But we really have to do something about the convolution painter, it's
> > performance is _catastrophic_. And around half of the time is spend in
> > memcpy of the pixels, which is mostly the difference between 1.5 and 1.6.
> > That's mostly to solve this problem that boud and me have consider the
> > lock region.
>
> Yeah, the other half is spent calling convolve in the colorspaces :-)
not really, it's only a quarter of the time. But you know, you have to spend 
cpu cycles at some point :D

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

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)

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

-- 
--- Cyrille Berger ---