When the filter ( <filter
id="f1"><feOffset dx="50" dy="50" /></filter>) is appled on
the shape
( <circle cx="85" cy="135"
r="50" filter="url(#f1)" />),
I can't find it by calling
"nodeHitAt(rootGraphicsNode)".
But another filter
( <filter
id="f1"><feSpecularLighting in="FillPaint" in2="SourceAlpha"
lighting-color="blue" result="specOut">
<fePointLight/>
</feSpecularLighting>
<feComposite
in="specOut" in2="SourceAlpha" operator="in"
result="specOut"/>filter>
) is no
problem.
thanks in advance
The nodeHitAt method is using the GraphicsNode's raw
geometry to determine whether or not it contains the (x, y)
coordinate . That means that any filter,
mask or clip is taken into account (similar to
getPrimitiveBounds).
The first filter you are using just translates
the graphic so the sensitive region of the circle is not really what's
displayed on the screen.
Now, being awared of how nodeHitAt is working right now, if
this is really an issue for you, I would suggest to submit us a patch that
provides a new method such as nodeHitAt that takes filter, clip, mask... into account (basically,
using the same idea than getPrimitiveBounds compared to
getBounds).
Then I am willing to rename the current nodeHitAt to
primitiveNodeHitAt (or equivalent) and add your new method as
nodeHitAt).
Thierry.
Thank you at first, you
let me see how nodeHitAt is working.
I am not master at
batik, I think, I don't have a clue to make "nodeHitAt" take those into
account..
However, To feOffset only,
If we regist the
invAffine of AffineRable8Bit as a new member of ShapeNode when
SvgFeOffsetBridge is working, We can transform the input point by invAffine
in "nodeHitAt". How do you think about?
Now, The batik browser
can't deal with the mouse event,
I expect some master can
make "nodeHitAt" take all of those into account.
Ma
zhenduo
