xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Ávila <asan...@nextech.com.br>
Subject Re: Synchronizing JSVGCanvas
Date Fri, 31 Mar 2006 21:51:22 GMT
Hi Thomas,

You are right. It turned out that all I had to do was to turn on double
buffering on the canvases. Now they are in perfect synch. Dynamic behavior
is a little slower than before, as one would expect, but this is absolutely
no problem.

I want to push it to see how many layers I can have working like this.
Anyway, it's looking really nice now.

Many thanks again!

----- Original Message ----- 
From: <thomas.deweese@kodak.com>
To: <batik-users@xmlgraphics.apache.org>
Cc: <batik-users@xmlgraphics.apache.org>
Sent: Friday, March 31, 2006 3:44 PM
Subject: Re: Synchronizing JSVGCanvas


> Hi Andre,
>
> André Ávila <asantos@nextech.com.br> wrote on 03/31/2006 01:37:04 PM:
>
> > > André Ávila <asantos@nextech.com.br> wrote on 03/31/2006 11:48:06 AM:
> > >
> > > > Hi Thomas,
> > > >
> > > > I tried your approach. Much simpler than mine, indeed, but you
> actually
> > > > lose the dynamic behavior of the interactors. Only after the mouse
> is
> > > > released, the other layers are transformed.
> > >
> > >    Then you just need to do exactly the same thing with the
> > > 'setPaintingTransform' method.  This will make them all move in
> unison.
> >
> > Ha! You're the man!
>
>     Are you setting the 'painting transform' on the 'child' canvases or
> the
> rendering transform?
>
> > > > So, I'm moving on to the overlay idea. I'm thinking, to do that I'll
> > > have to rasterize the svgs first, right?
> > >
> > >    If you manipulate the setPaintingTransform this will happen
> > > automatically. It will pan/scale/rotate/etc the offscreen bitmap
> > > rather than rerender the content.  Everything should be fairly
> > > quick unless you have huge canvases or many layers.
> >
> > Yes, I'm afraid this is exactly the problem. The SVGs I deal with are
> really
> > complex, and the smaller ones have around 100KB (the bigger ones have
> more
> > than 10MB - enters the rendering with JGVTComponent). In fast machines
> the
> > synch is probably acceptable, although far from perfect. But in less
> > powerful ones, it gets really bad, even with only 2 layers of 100KB
> SVGs.
>
>    If you are manipulating the just the painting transform on all the
> canvases
> then you are simply compositing the bitmaps, the speed will be a function
> of the
> size _in_pixels_ of the canvas (and number of canvas layers) - it doesn't
> matter
> how complex the SVG content is in this case.  It's just pushing bitmaps
> around.
>
> > >    It might be made to work, but setPaintingTransform is the way to
> go...
> >
> > setPaintingTransform seems to work really fine in the general case of
> > decent-sized SVGs, but given the requirements I have I'll have to find
> > another solution.
>
>   I don't think you can do better than the setPaintingTransform approach,
> unless you 'premerge' the layers at the start of the PaintingTransform
> manipulation.  But I'm guessing that you are translating PaintingTransform
> changes in the top canvas into Rendering transform changes in the lower
> layers...
>
> > Thinking about the overlay, I just realized that will be
> > very difficult to keep the vector lossless scaling, since I'll be
> dealing
> > with a rasterization of an SVG. Oh, boy. Any other ideas are most
> welcome!
>
>    The painting transform is already doing this, use the interactive
> 'scale in'
> command (shift mouse 2) and it will pixelate the content until it
> rerenders
> the canvas (if your lower canvas's don't pixelate then you aren't doing it
> right ;)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Mime
View raw message