You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Luca Piccarreta <lu...@gmail.com> on 2008/07/21 12:10:24 UTC
Flickering while changing scale
Hi all,
I suspect there is a "bug", if we can call it so, in Batik.
Changing zoom and/or pan through the DOM APIs cause immediate
repaint irrespective of the suspendRedraw API.
Can anyone confirm that?
We implemented a sort of non-scalable stroke by changing on the fly
stroke-width attributes depending on the zoom. And this causes a
nasty flashing effect.
Thanks in advance,
Luca Piccarreta
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Flickering while changing scale
Posted by th...@kodak.com.
Hi Luca,
"Luca Piccarreta" <lu...@gmail.com> wrote on 07/22/2008 07:46:36
AM:
> if I get it right suspendRedraw() is all about suspending
> communication between document and view (here I suppose that
> there is a sort of MVC in Batik).
You are correct that there is a sort of MVC in Batik. The
Model is the SVG document, the View is the GVT tree, and the
Controller is the Bridge(s). But suspendRedraw doesn't interrupt
any of that communication because if it did changes would be lost
and we would have to rebuild the entire GVT tree from scratch.
What it does suspend is actual triggering of repaints in
the UpdateManager. This is not the problem at all.
> And this could explain why this "glitch" can be so nasty to correct.
> If you come up with a simple solution sketch (me know nothing about
batik),
> I'll be glad to try and help.
The glitch is caused by the fact that the global rendering transform
isn't handled by the UpdateManager it's handled by the Canvas directly.
This is mostly a legacy from when Batik didn't handle dynamic SVG
documents at all. So the Canvas would manage the only dynamic part
which was the viewing/rendering transform, so you could zoom in and
pan around a document.
As a result of this history, rendering transform changes are
still handled by the canvas, and a change to the rendering transform
causes the canvas to trigger a repaint that is more or less unknown
by the UpdateManager.
The correct solution to this problem would probably be to push
the renderingTransform into the UpdateManager stuff (although that
would make problems for static documents). However the 'simple'
solution I would propose would be to expose the 'allResumeTime'
on the UpdateManager (or perhaps add a 'areRepaintsSupsended'
method that checks allResumeTime internally; >=0 means repaint
is suspended). Then the JSVGCanvas can override 'scheduleGVTRendering'
to check the UpdateManager (if it is not null, and call the
JGVTCanvas.scheduleGVTRendering method only if repaints aren't
suspended).
> I've no idea whatsoever about how to fix this issue.
Does the above make sense?
> On Tue, Jul 22, 2008 at 12:32 PM, <th...@kodak.com> wrote:
>
> Hi Luca,
>
> Luca Piccarreta <lu...@gmail.com> wrote on 07/21/2008 06:10:24
AM:
>
>
> > I suspect there is a "bug", if we can call it so, in Batik.
> > Changing zoom and/or pan through the DOM APIs cause immediate
> > repaint irrespective of the suspendRedraw API.
> > Can anyone confirm that?
>
> I can confirm it. I'll also confirm that fixing it isn't
> trivial ;) The basic problem is that the 'renderingTransform'
> (which is what the zoom/pan API adjusts) is handled by the
> Swing component which doesn't currently know much about the
> suspendRedraw stuff.
>
> > We implemented a sort of non-scalable stroke by changing on the fly
> > stroke-width attributes depending on the zoom. And this causes a
> > nasty flashing effect.
> Yes, there is some ugliness between the zoom/pan API stuff
> (including notification events) and other dom actions. Right
> now I don't have a good suggestion for a work around other than
> to try and fix the canvas in this regard. I'd be happy to help
> provide guidance if you are interested in contributing.
Re: Flickering while changing scale
Posted by Luca Piccarreta <lu...@gmail.com>.
Hi Thomas,
thanks for answering.
if I get it right suspendRedraw() is all about suspending communication
between
document and view (here I suppose that there is a sort of MVC in Batik).
And this could explain why this "glitch" can be so nasty to correct.
If you come up with a simple solution sketch (me know nothing about batik),
I'll be glad to try and help.
Luca.
I've no idea whatsoever about how to fix this issue.
On Tue, Jul 22, 2008 at 12:32 PM, <th...@kodak.com> wrote:
>
> Hi Luca,
>
> Luca Piccarreta <lu...@gmail.com> wrote on 07/21/2008 06:10:24
> AM:
>
> > I suspect there is a "bug", if we can call it so, in Batik.
> > Changing zoom and/or pan through the DOM APIs cause immediate
> > repaint irrespective of the suspendRedraw API.
> > Can anyone confirm that?
>
> I can confirm it. I'll also confirm that fixing it isn't
> trivial ;) The basic problem is that the 'renderingTransform'
> (which is what the zoom/pan API adjusts) is handled by the
> Swing component which doesn't currently know much about the
> suspendRedraw stuff.
>
> > We implemented a sort of non-scalable stroke by changing on the fly
> > stroke-width attributes depending on the zoom. And this causes a
> > nasty flashing effect.
>
> Yes, there is some ugliness between the zoom/pan API stuff
> (including notification events) and other dom actions. Right
> now I don't have a good suggestion for a work around other than
> to try and fix the canvas in this regard. I'd be happy to help
> provide guidance if you are interested in contributing.
>
Re: Flickering while changing scale
Posted by th...@kodak.com.
Hi Luca,
Luca Piccarreta <lu...@gmail.com> wrote on 07/21/2008 06:10:24
AM:
> I suspect there is a "bug", if we can call it so, in Batik.
> Changing zoom and/or pan through the DOM APIs cause immediate
> repaint irrespective of the suspendRedraw API.
> Can anyone confirm that?
I can confirm it. I'll also confirm that fixing it isn't
trivial ;) The basic problem is that the 'renderingTransform'
(which is what the zoom/pan API adjusts) is handled by the
Swing component which doesn't currently know much about the
suspendRedraw stuff.
> We implemented a sort of non-scalable stroke by changing on the fly
> stroke-width attributes depending on the zoom. And this causes a
> nasty flashing effect.
Yes, there is some ugliness between the zoom/pan API stuff
(including notification events) and other dom actions. Right
now I don't have a good suggestion for a work around other than
to try and fix the canvas in this regard. I'd be happy to help
provide guidance if you are interested in contributing.