On Wed, 31 Dec 2003, Thomas DeWeese wrote:
> > On Tue, 30 Dec 2003, Thomas DeWeese wrote:
>
> There is the possibility of using just the JGVTComponent with a GVT
> tree for static content. Currently this references is the only
> reference from GVT to DOM (or bridge) - if it went away then you could
> construct the GVT tree and let the DOM tree be GC'd.
[...]
> For a Dynamic document the reference could never go away.
Ah, cool. Manually create the GVTTreeBuilder, etc.? Nice. :-)
> > [..]I needed to be able to recieve events even if the user
> > clicked in an area of the SVGCanvas which did not contain part of the SVG.
> >
> > Looking back, I could just have tossed a full-size rectangle (maybe
> > even a transparent rectangle) as the first SVGElement in the DOM after
> > loading it, and taken it out when saving, which would have allowed me to get
> > the events I needed and allowed me to use GVTEvents / DOMEvents.
>
> This is the time tested hack to support this in SVG. With the
> current versions of batik you can use:
>
> <rect x="-1000%" y="-1000%" width="2000%" height="2000%"
> fill="none" stroke="none" stroke-width="0"
> pointer-events="fill"/>
Ooooh! Eeeeexcellent. *taps fingers together* :-)
Thank you. :-)
> > Maybe if I get time, I'll rewrite things in this cleaner manner; but I'm on
> > a schedule now. (and maybe there are other possibilities I didn't try...
> > *shrug* it's been a while; I can't even remember what I /did/ try ;-).
>
> The above would probably greatly simplify your life :)
> The one real advantage of interactors is that they are 100% modal.
> So no one else get's any events when an interactor is active - they
> are also good to avoid the overhead of DOM event dispatch (which can
> be expensive - locating target etc.) But if what you want to do in
> the end is modify the DOM - DOM events are almost always easier to
> work with.
And truth be told, part of the reason I did it was performance:
when you're dragging the mouse around the screen (and moving an outline
with it), the overhead of digging into the DOM and walking back out is
noticeable. Now, the clicking and the starting of the drag is a different
manner; that could probably be handled with the DOM for simplicity's sake.
Speaking of dragging, though (and since we're on the topic of
text): how do I get text painted (quickly) into a BufferedImage?
When I tried simply creating a BufferedImage and telling the
relevant GraphicsNodes to paint into its Graphics2D context, I got
messages about how certain keys weren't set and I should use some Batik
methods to create such an image. When I used the aforementioned Batik
methods to create the BufferedImage, then anytime I painted a GraphicsNode
into it, the JSVGComponent thought it needed to be re-rendered, which
killed performance.
The other thing I've done is get outlines of the relevant
GraphicsNodes and draw those while moving. This is fine 90% of the time,
but when I try dragging around the "Henry V" example from the Batik
Samples, I sometimes wait more than a minute for it to generate the
outline -- and at least 20 seconds for it to render it -- on a fast
computer. Which is to be expected, I suppose. But... I have no
need/desire to use the node's official outline; I just want to show the
user something along the lines of what they're moving. A 'getShape()' or
'draw()' or whatnot that /didn't/ tell the JSVGComponent to re-render
would be fine with me... ;-)
Thanks!
- Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
