Too many bitBlts?

[Sven Langkamp]

Am Sonntag, 10. Juli 2005 16:28 schrieb 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.

I'm just wondering why the selection is so slow. At the moment creating a 
selection is much slower than it was sometime ago.