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: <[EMAIL PROTECTED]> To: <[email protected]> Cc: <[email protected]> Sent: Friday, March 31, 2006 3:44 PM Subject: Re: Synchronizing JSVGCanvas > Hi Andre, > > André Ávila <[EMAIL PROTECTED]> wrote on 03/31/2006 01:37:04 PM: > > > > André Ávila <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
