Infinite canvas issues

[Boudewijn Rempt]

On Wednesday 01 July 2009, LukasT.dev at gmail.com wrote:
> > > Could you direct me to the code? It is in paintEvent of
> > > the QPainterCanvas? ev->rect? I tried that but without luck (I moved
> > > that rect but I did not see what i painted until i scrolled with wheel
> > > to generate event and have updated widget)
> >
> > The relevant code is in KisQPainterCanvas::paintEvent, and if you look
> > closely you can see the likely cause of the problem. From your video, the
> > checkers are drawn at a different place from the lines. In the
> > KisQPainterCanvas::paintEvent code, you can see that we always draw the
> > checkers first and then the line (this is not totally optimal, but that
> > is not the question now).
> >
> > Now, you can see that checkers are drawn using a translation that uses
> > m_d-
> >
> > >documentOffset, while the actual cached, prescaled projection is drawn
> >
> > directly. And I think that that's the problem: your document offset isn't
> > correct here.
>
> Hi,
>
> I was exploring the issues today I made a new video with debug_paint
> uncommented [2].
>
> I was asking on IRC about "paint preview" (named it direct paint or
> something). What is wrong now is that there is some rectangle that is
> constantly updated as you paint and it allows you to see what are you
> painting. This rectangle has to be translated by documentOffset (i think)
> and by new documentOrigin (m_d->origin) which I added when implementing
> infinite canvas according Karbon canvas.
>
> In KisQPainterCanvas::paintEvent
> I tried to create new variable by move the m_d->documentOffset by origin
> and use it in places instead of m_d->documentOffset.
>
> I tried to use copy of the ev->rect() and translate that by origin. Both
> did not help.
>
> There are methods
> KisCanvas2::updateCanvasProjection(const QRect & rc)
> KisCanvas2::updateCanvas(const QRectF& rc)
>
> there is not documentation for them but you can read in implementation that
> they are called by tools so I expect that they update the part of the
> widget specified by rc. I tried to translate the rc by origin.Did not help
> too.
>
> You can check my updated patch [2].

This you really need to debug yourself. Your second video shows exactly the 
same thing as the previous video, namely that as soon as the drawable area 
becomes larger than the image, the painting itself still happens relative to 
the image origin, and the initial updates in paintEvent relative to the origin 
of the expanded canvas.

For additionaly fun, try to scroll in addition to zooming.

So: 
you have the image, with an topleft of 0,0
you have the canvas widget
you have the layers, that can extend beyond the image bounds
you now also can paint outside the image bounds (which should go to the right 
place on the canvas, so in the case of your video with negative image 
coordinates)
and if you paint outside the image bounds, you shouldn't even update the image 
projection, since no new visible things are painted.

>
> Cyrille suggested to look at kis_layer_* but I think it is too far from
> canvas
>
> :) ?
>
> LukasT: CyrilleB: do you know where is direct paint handled in canvas?
> LukasT: CyrilleB: could it be decoration and is it tool specific?
> CyrilleB: LukasT: it's done as a special layer in kis_layer_*

That is totally irrelevant and only caused by using imprecise terminology: 
your problem has _nothing_ to do with direct or indirect painting. This is 
completely, entirely and absolutely a red herring.

>
> (I meant paint preview as direct paint is something different..)
>
> [1] http://lukast.mediablog.sk/videos/krita2-canvas_debug.ogv
> [2] http://lukast.mediablog.sk/patches/qpainter_infinite_canvas.1.patch


-- 
Boudewijn Rempt | http://www.valdyas.org