From kde-kimageshop  Sun Jul 10 20:04:05 2005
From: Sven Langkamp <longamp () reallygood ! de>
Date: Sun, 10 Jul 2005 20:04:05 +0000
To: kde-kimageshop
Subject: Re: Too many bitBlts?
Message-Id: <200507102204.06306.longamp () reallygood ! de>
X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=112102607524585

Am Sonntag, 10. Juli 2005 21:10 schrieb Casper Boemann:
> On Sunday 10 July 2005 20:39, Sven Langkamp wrote:
> > 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.
> > _______________________________________________
> > kimageshop mailing list
> > kimageshop@kde.org
> > https://mail.kde.org/mailman/listinfo/kimageshop
>
> Yes I'm wondering about that too
>
> If you deselect and reselect the update
> you see
> krita (core) : KisImage::slotSelectionCreated
> krita (core) : KisSelectionManager::imgSelectionChanged
> krita (core) : KisImage::slotSelectionChanged
> krita (core) : KisSelectionManager::imgSelectionChanged
> krita (core) : KisImage::slotSelectionCreated
> krita (core) : KisSelectionManager::imgSelectionChanged
>
> and even worse when selecting a rect:
> (core) : KisImage::slotSelectionCreated
> krita (core) : KisSelectionManager::imgSelectionChanged
> krita (core) : KisImage::slotSelectionChanged
> krita (core) : KisSelectionManager::imgSelectionChanged
> krita (core) : KisImage::slotSelectionCreated
> krita (core) : KisSelectionManager::imgSelectionChanged
> krita (core) : KisImage::slotSelectionChanged
> krita (core) : KisSelectionManager::imgSelectionChanged
> krita (core) : Selected rect: x:128, y: 128, w: 256, h: 192
> krita (core) : KisImage::slotSelectionChanged
> krita (core) : KisSelectionManager::imgSelectionChanged
> krita (core) : KisImage::slotSelectionChanged
> krita (core) : KisSelectionManager::imgSelectionChanged
>
> wheas when deselecting you only see it once

Thanks for the hint. I have located a part of the problem, which I'm going to 
fix now.
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop