Hi Michael, "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on 12/02/2005 08:09:40 AM:
> OK, you're right; adding a viewBox isn't terribly difficult. Where do I get > the bounds for this viewBox? It seems like it would change when I scroll the > canvas? Is it the size of the document itself that I can ask the JSVGCanvas for? The viewBox should be the 'total extent' of the document. It does not change when you scroll the document. It _might_ change when someone drags an object 'outside' of the current bounds of the document, this would be up to your application (does the canvas have a fixed extent or does it grow and shrink as people drag things around). You could ask the root SVG element for it's BBox if you want it to be dynamic but you need to do it in the update manger thread. For example you might want to query the bbox at the end of a drag operation and update the viewbox if it has changed. Be careful however as changing the width/height of the viewBox will cause the entire graphics tree to be rebuilt (to properly update properties/attributes that use '%'). > ________________________________ > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Fri 12/2/2005 6:02 AM > To: [email protected] > Subject: Re: Drag and drop breaks with a JSVGScrollPane? > > > > Hi Michael, > > "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on > 12/01/2005 10:58:07 AM: > > > I added a JSVGScrollPane around my JSVGCanvas. Now I'm getting random > NPEs > > when dragging an element around the canvas. This looks thread-related, > but my > > drag and drop code hasn't changed. I'm updating the document in the > > JSVGCanvas's UpdateManager with a Runnable. Here's the stack trace: > > This looks like a bug in the JSVGScrollPane (it's looking at GVT stuff > outside of the update manager thread). The fix is pretty simple however, > add a viewBox attribute to the root SVG element. This is a good idea > anyways. > > The problem is that if there is no viewbox the canvas tries to be > nice and look at the actual bounds of the GraphicsNode and use that > instead. The problem is that unless it does that in the UpdateManager > thread your code could have invalidated the bounds information at the > same time - in which case it just returns a null BBox. > > Probably the 'right' thing to do is for the canvas to 'cache' the > bounds of the GVT tree for each rendering/update - then the scroll pane > can just get that. I get nervous about adding invokeAndWait calls > in the ScrollPane as it may cause lots of people to have lock ups. > > > Is there something else I need to manage when I have a JSVGScrollPane? I > just > > wanted to be able to scroll around the canvas when I'm zoomed in. All I > did > > was wrap the JSVGCanvas in the JSVGScrollPane. Oddly enough, this error > > > occurs if I don't even add the JSVGScrollPane to the application. As > long as > > I call its constructor with the JSVGCanvas as the parameter, the error > happens. > > Yes, when the JSVGScrollPane is constructed it attaches it's self to > the > update callbacks of the canvas so it can keep the scrollbars in sync > (really > all the scroll pane does is offer visual feedback and manipulation of the > existing scrolling support in the canvas). > > > > [attachment "winmail.dat" deleted by Thomas E. DeWeese/449433/EKC] > --------------------------------------------------------------------- > 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]
