Too many bitBlts?

[Boudewijn Rempt]

On Sunday 10 July 2005 16:14, Casper Boemann wrote:
> On Sunday 10 July 2005 12:57, Michael Thaler wrote:
> > On Sunday 10 July 2005 12:37, Casper Boemann wrote:
> > > screen rendering does it in 128x128 blocks afaik
> > > don't really know why - I just did it like it was already when I
> > > refactored it with the new tile system.
> >
> > If I remember correctly, the original idea was to update only tiles that
> > are marked as dirty. Because this is too slow, not single tiles are
> > repainted, but 2 x 2 areas. I think there is a dirty bool (or at least
> > there was) but I am not sure if this was/is actually ever used.
>
> yes that was the idea, but now we use a dirtyRect instead and update
> immediately. As I recall the dirty flag was removed about half a year ago
> by boudewijn.

The current system is the original system; I experimented with a timer that at
screen refresh interval rates repainted the dirty bits of the screen. On my
laptop that worked fine, but Sven told me that on his slower machine this 
produced noticable lack. We use 128x128 blocks to make reasonably sure we 
have a chance of having a longish stretch of pixels to feed to the composite 
functions. It is easy to experiment with; you can make the area updated in 
one go bigger of smaller, but in my experience, but slow Krita down a lot. 
And there's also some X dependency that makes 128x128 optimal, or so Patrick 
Julien told me some time ago.

-- 
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: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050710/7f6ad185/attachment.pgp