I have finally a beginning of response. Since I would modify the interactivity mostly with polylines, I have made some preliminary tests using differents implementations of gvt/StrokeShapePainter.getPaintedArea (I instantiate a new BasicStroke on which I can hack ad return just in palce of the original) with a pointer-event equals to stroke.
Renaud 2009/11/20 <[email protected]>: > Hi Renaud, > > BTW this discussion should really take place on batik-users since it > doesn't involve > development of Batik. > > Renaud AUBIN <[email protected]> wrote on 11/19/2009 02:58:28 PM: > >> Is there a way to do that at a lower level to optimize the processing? > > Feel free to inspect the code that currently does the intersection > testing at: > batik.bridge.SVGSVGElementBridge > > I don't think you will find significant optimizations in that > code. > >> If not, any clues about where the geometrical processing is really >> done are welcomed! > > What you might consider doing (at the cost of memory) would be > to 'duplicate' your lines with a wider stroke (probably using a 'use' > element). You can make the duplicate invisible (fill="none" stroke="none") > but still sensitive to mouse events (pointer-events="all"). > > >> 2009/11/6 jonathan wood <[email protected]>: >> > >> > Hi Renaud, >> > >> > This is a shot in the dark based on you description. >> > >> > The basic problem I distilled: You need fuzzy control over mouse >> > selection.. >> > >> > I've solved this in the past by obtaining the selection or currentpoint >> > x,y >> > (using a glasspane etc) and then checking your configurable fuzzy bounds >> > by >> > creating a rect centered on the point and use getIntersectionList or >> > getEnclosureList to determine what is within rect/2 distance of the >> > cursor. >> > >> > Hope this helps...good luck! >> > >> > On Fri, Nov 6, 2009 at 3:01 PM, Renaud AUBIN <[email protected]> >> > wrote: >> >> >> >> Hello, >> >> >> >> I'm currently trying to figure out where and how a target is >> >> identified with respect to mouse events. >> >> The main issue is that the current interaction model (from w3c >> >> recommandations) is not really adapted to our needs. >> >> >> >> The big picture: we have 2D P&ID diagrams with a lot of pipes to >> >> interact with. This kind of diagram is very useful to prepare >> >> operations on real process with a good functionnal view of what we are >> >> going to do... but that's only true at a certain zoom level! As a >> >> consequence, we need to be able to interact (focusIn, focusOut, click) >> >> with polylines of limited stroke width at a "global" zoom level. >> >> Actually, we can interact with a pipe's polyline only when the mouse >> >> pointer is *exactly* over the polyline. Now, our users' need drive us >> >> to the point that we really need to modify this behaviour. So we need >> >> to modify batik to provide magnetism-like interaction or a targetable >> >> polyline with a (maybe) configurable distance (i.e. we don't need to >> >> be over the line but at a configurable distance in screen space for >> >> example with zoom-dependant thresholds). >> >> >> >> Any suggestions on where to begin to save us some time ? >> >> >> >> Best regards, >> >> >> >> Renaud >> >> >> >> --------------------------------------------------------------------- >> >> 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] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
