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
