stuckness :-(

[Sven Langkamp]

On 9/29/07, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Friday 28 September 2007, Cyrille Berger wrote:
> > > But I'm stuck; even with the "normal" path (caching, blitz < 1.0, sample
> > > 1.0-2.0, qpainter scaling > 2.0), I get artefacts and the canvas thinks
> > > the image is bigger than it really is.
> > >
> > > I don't want to commit, since it breaks Krita horribly, but I would
> > > appreciate any help! So here's the patch, if the mailing list lets it
> > > through...
> >
> > Here is what I see : when zooming out I have no problem, I haven't seen
> any
> > problem when drawing, but when zooming in, only the top left quarter of
> the
> > image is displayed, but when painting on the new area it works for a while
> > and then crash.
> >
> > Is that what you have also ? Or is there an other problem ?
>
> I have different problems -- when I use the pixel-for-pixel mode,
> when I scale down, to < 100%, everything works. But when I scale up, there
> are
> certain transitions, like from 42% to 50% where small bands of distortion
> appear. (see attached screenshot). This doesn't happen when I run the
> unittest on lena :-(. Then, when going beyond 100%, I get checks on the
> right, that show that the docsize somehow is set to be bigger than than the
> scaled image. See the other attachment.
I may be one the wrong track, but I thought I would share my observations.

Here are the steps I did:
I used a 200x200 image, zoomed to 50% and the back to 100%.
The result is that in the topleft area the image is shown while the
rest is checkers. You can see that the checkers have the right size
while the image is still at the 50% size. After painting on it the
image is correcty updated.

I assumption is that somehow the image is scaled to the old canvas
size and then the canvas is resize. I tried to force an update in the
paintEvent by calling updateCanvasProjection which seems to fix the
problem for case that documentoffset is 0.

I hope this can help.

> > I tried on XRender accelerated hardware and it was very slow, but maybe
> all
> > the piece aren't yet together or the debug information are the cause.
>
> Debug eats a bit, but on Xrender hardware it should be pretty fast. It's
> even
> fast on my desktop machine, which is a really slow beast with a really
> stupid
> video card. So that needs investigation.
Painting is really slow here. No accelerated XRender though,