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 emzic <em...@embege.com> on 2008/07/15 17:44:46 UTC
simulating batik's DOMMouseEvents
hello,
i use batik to rasterize an svg to a bufferedimage, which obviously looses
all of the nice interactivity.
so EventListeners like this will obviously not work anymore:
EventListener el = new EventListener() {
public void handleEvent(Event evt) {
}
};
someNode.addEventListener("click", el, false);
now since i still would like to use interaction like this in the
bufferedimage, i thought of faking these Events.
whenever an AWT-Event occurs on the BufferedImage i will need to translate
it into a DOMMouseEvent and dispatch that to the original SVGDocument, from
which the BufferedImage was rasterized and still exists in memory.
so what i did was use the DOMMouseEvent.initMouseEventNS(...) function to
create a DOMMouseEvent and then dispatch that on the root-node of the
svgdocument.
the problem is, that the eventhandlers are just not triggered. but i could
yet not find out where exactly they get lost.
thanks for any help on this!
--
View this message in context: http://www.nabble.com/simulating-batik%27s-DOMMouseEvents-tp18468447p18468447.html
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: simulating batik's DOMMouseEvents
Posted by emzic <em...@embege.com>.
thomas.deweese wrote:
>
> Dynamic uses more memory and has more overhead than interactive.
> I think you only need interactive.
>
yes, setInteractive did the trick! thank you very very much, thomas.dewesse!
--
View this message in context: http://www.nabble.com/simulating-batik%27s-DOMMouseEvents-tp18468447p18486352.html
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: simulating batik's DOMMouseEvents
Posted by th...@kodak.com.
Hi Emzic,
> thomas.deweese wrote:
> > If you were using the Transcoders to generate your buffered image
then
> > you will need to either subclass or 'copy and paste' the transcoder
> > code so you can hold onto the BridgeContext and GVT tree. Without the
> > GVT tree you can't do anything that relies on geometry (like figuring
out
> > what element is under a particular point), and the BridgeContext
allows
> > you to map between the GVT tree and the DOM tree.
emzic <em...@embege.com> wrote on 07/16/2008 07:58:18 AM:
> thanks a lot! now i understand what this bridge is for. it links between
the
> GVT tree and the DOM tree, right?
Correct.
> also i could get some code running now, that find s a "shape" at a
certain
> position. but when i try to get the DOM-element of this shape it only
finds
> null.
> GraphicsNode result = gvtRoot.nodeHitAt(p); // finds a shape
> bridgeContext.getElement(result); // returns null
> does that mean that there is no corresponding DOM element to that GVT
> element?
No it means that your BridgeContext wasn't configured to
retain the mapping information. Depending on your needs
you may need to set the BridgeContext 'dynamicState' to at
least INTERACTIVE and possibly DYNAMIC:
bctx.setInteractive(true);
-or-
bctx.setDynamic(true);
Dynamic uses more memory and has more overhead than interactive.
I think you only need interactive.
Re: simulating batik's DOMMouseEvents
Posted by emzic <em...@embege.com>.
thomas.deweese wrote:
>
> Well this is just a way to get the root graphics node (root of the
> GVT tree) associated with the Canvas. This is the same root graphics
> node that you must have created to rasterize the document.
>
>> my specific situation is, that i dont have a canvas, but just a readily
>> rasterized bufferedimage as i said above. (the reason for this is, that
> the
>> image is actually used as an openGL texture.) still i would like to get
> the
>> element that is below the mousecursor.
>
> If you were using the Transcoders to generate your buffered image then
> you will need to either subclass or 'copy and paste' the transcoder
> code so you can hold onto the BridgeContext and GVT tree. Without the
> GVT tree you can't do anything that relies on geometry (like figuring out
> what element is under a particular point), and the BridgeContext allows
> you to map between the GVT tree and the DOM tree.
>
thanks a lot! now i understand what this bridge is for. it links between the
GVT tree and the DOM tree, right?
also i could get some code running now, that find s a "shape" at a certain
position. but when i try to get the DOM-element of this shape it only finds
null.
GraphicsNode result = gvtRoot.nodeHitAt(p); // finds a shape
bridgeContext.getElement(result); // returns null
does that mean that there is no corresponding DOM element to that GVT
element?
thanks a lot for your help, thomas.deweese!
--
View this message in context: http://www.nabble.com/simulating-batik%27s-DOMMouseEvents-tp18468447p18485590.html
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: simulating batik's DOMMouseEvents
Posted by th...@kodak.com.
Hi Emzic,
emzic <em...@embege.com> wrote on 07/16/2008 06:53:17 AM:
> thomas.deweese wrote:
> >
> > In the e-mail thread with Hardc0d3r I showed how to find the
element
> > at a particular point that should be the targetElement (read the
thread
> > starting with my first response):
> >
> > http://www.nabble.com/getting-the-element-in-svg-from-an-overlay-
> to18301441.html
> >
> >
> thanks a lot for your help.
>
> i read that article and studied the code, but it seems as if it requires
> some JSVGCanvas where the svg is drawn in order to call the function
>
> canvas.getGraphicsNode().nodeHitAt(gnp);
Well this is just a way to get the root graphics node (root of the
GVT tree) associated with the Canvas. This is the same root graphics
node that you must have created to rasterize the document.
> my specific situation is, that i dont have a canvas, but just a readily
> rasterized bufferedimage as i said above. (the reason for this is, that
the
> image is actually used as an openGL texture.) still i would like to get
the
> element that is below the mousecursor.
If you were using the Transcoders to generate your buffered image then
you will need to either subclass or 'copy and paste' the transcoder
code so you can hold onto the BridgeContext and GVT tree. Without the
GVT tree you can't do anything that relies on geometry (like figuring out
what element is under a particular point), and the BridgeContext allows
you
to map between the GVT tree and the DOM tree.
Re: simulating batik's DOMMouseEvents
Posted by emzic <em...@embege.com>.
thomas.deweese wrote:
>
> In the e-mail thread with Hardc0d3r I showed how to find the element
> at a particular point that should be the targetElement (read the thread
> starting with my first response):
>
> http://www.nabble.com/getting-the-element-in-svg-from-an-overlay-to18301441.html
>
>
thanks a lot for your help.
i read that article and studied the code, but it seems as if it requires
some JSVGCanvas where the svg is drawn in order to call the function
canvas.getGraphicsNode().nodeHitAt(gnp);
my specific situation is, that i dont have a canvas, but just a readily
rasterized bufferedimage as i said above. (the reason for this is, that the
image is actually used as an openGL texture.) still i would like to get the
element that is below the mousecursor.
thanks for any help on this problem!
--
View this message in context: http://www.nabble.com/simulating-batik%27s-DOMMouseEvents-tp18468447p18484934.html
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: simulating batik's DOMMouseEvents
Posted by th...@kodak.com.
Hi Emzic,
> thomas.deweese wrote:
> > You can find the element under the mouse via the code I recently
> > posted to help hardc0d3r. Our code to dispatch the DOM events lives
> > in batik.bridge.BridgeEventSupport (but it relies on the graphics node
> > already being found).
emzic <em...@embege.com> wrote on 07/16/2008 05:40:04 AM:
> now the event is triggered!
Good.
> but the target that is in the event is the whole SVG. i would like to
get
> only the element (path, rect, circle, ...) that is under the
mousecursor.
>
> i think i will need to look into this BatikBridge you mentioned.
In the e-mail thread with Hardc0d3r I showed how to find the element
at a particular point that should be the targetElement (read the thread
starting with my first response):
http://www.nabble.com/getting-the-element-in-svg-from-an-overlay-to18301441.html
Re: simulating batik's DOMMouseEvents
Posted by emzic <em...@embege.com>.
thomas.deweese wrote:
>
> You should use SVGDocument.createEvent("MouseEvents") instead
> (I don't think this is actually the problem here but it will
> help future proof your code).
>
>
> Also you need to make sure you dispatch the event to the EventTarget
> under the mouse event:
>
> ((EventTarget)targetElement).dispatchEvent(mouseEvt);
>
> You can find the element under the mouse via the code I recently
> posted to help hardc0d3r. Our code to dispatch the DOM events lives
> in batik.bridge.BridgeEventSupport (but it relies on the graphics node
> already being found).
>
>
thanks a lot!
now the event is triggered!
but the target that is in the event is the whole SVG. i would like to get
only the element (path, rect, circle, ...) that is under the mousecursor.
i think i will need to look into this BatikBridge you mentioned.
--
View this message in context: http://www.nabble.com/simulating-batik%27s-DOMMouseEvents-tp18468447p18483902.html
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: simulating batik's DOMMouseEvents
Posted by th...@kodak.com.
Hi Emzic,
emzic <em...@embege.com> wrote on 07/15/2008 11:44:46 AM:
> whenever an AWT-Event occurs on the BufferedImage i will need to
translate
> it into a DOMMouseEvent and dispatch that to the original SVGDocument,
from
> which the BufferedImage was rasterized and still exists in memory.
>
> so what i did was use the DOMMouseEvent.initMouseEventNS(...) function
to
> create a DOMMouseEvent and then dispatch that on the root-node of the
> svgdocument.
You should use SVGDocument.createEvent("MouseEvents") instead
(I don't think this is actually the problem here but it will
help future proof your code).
> the problem is, that the eventhandlers are just not triggered. but i
could
> yet not find out where exactly they get lost.
Also you need to make sure you dispatch the event to the EventTarget
under the mouse event:
((EventTarget)targetElement).dispatchEvent(mouseEvt);
You can find the element under the mouse via the code I recently
posted to help hardc0d3r. Our code to dispatch the DOM events lives
in batik.bridge.BridgeEventSupport (but it relies on the graphics node
already being found).