You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by th...@kodak.com on 2009/11/20 12:03:14 UTC
Re: Mouse Interaction behavior
Hi Renaud,
BTW this discussion should really take place on batik-users since it
doesn't involve
development of Batik.
Renaud AUBIN <re...@gmail.com> 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 <jo...@gmail.com>:
> >
> > 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 <re...@gmail.com>
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: batik-dev-unsubscribe@xmlgraphics.apache.org
> >> For additional commands, e-mail:
batik-dev-help@xmlgraphics.apache.org
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>
Re: Mouse Interaction behavior
Posted by Renaud AUBIN <re...@gmail.com>.
> 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.
Ok, at first sight, SVGSVGElement and/or gvt modifications should do well…
Mea culpa, I don't mean to do optimizations in a strict geometrical or
batikish POV but rather as our end users' POV.
> 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").
We have CAD Schemas and for some of them we have quite a lot of
primitives. We have thought about that already some times ago but it
seems to us that the performance and the memory usage will really
suffer.
Renaud
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Mouse Interaction behavior
Posted by Renaud AUBIN <re...@gmail.com>.
Hi Thomas,
I have in fact submitted this topic on the dev side because I don't
want to 'duplicate' my primitives but hack batik internals to fit my
needs.
It's not really related to batik-dev since what I would get is out of
specs wrt to W3C SVG recom, but it's no more or less related to
batik-user…
Renaud
2009/11/20 <th...@kodak.com>:
> Hi Renaud,
>
> BTW this discussion should really take place on batik-users since it
> doesn't involve
> development of Batik.
>
> Renaud AUBIN <re...@gmail.com> 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 <jo...@gmail.com>:
>> >
>> > 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 <re...@gmail.com>
>> > 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: batik-dev-unsubscribe@xmlgraphics.apache.org
>> >> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Mouse Interaction behavior
Posted by Helder Magalhães <he...@gmail.com>.
Hi everyone,
> BTW this discussion should really take place on batik-users since it
> doesn't involve
> development of Batik.
True, note that I'm now only replying to batik-users.
>> 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").
For this, SVG Tiny 1.2's non-scaling stroke (see "vector-effect" [1])
would be *really* useful. :-)
I've already though of a possible implementation based in a recent
thread about invariant text which ended up in a Wiki contribution [2];
unfortunately, I see no time frame to put my hands on this in the
short/medium term... Should a bug be created in order to start
gathering ideas? Any adepts/volunteers to help with this?
Cheers,
Helder
[1] http://www.w3.org/TR/SVGTiny12/painting.html#VectorEffectProperty
[2] http://wiki.apache.org/xmlgraphics-batik/CanvasTextSize
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Mouse Interaction behavior
Posted by Renaud AUBIN <re...@gmail.com>.
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 <th...@kodak.com>:
> Hi Renaud,
>
> BTW this discussion should really take place on batik-users since it
> doesn't involve
> development of Batik.
>
> Renaud AUBIN <re...@gmail.com> 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 <jo...@gmail.com>:
>> >
>> > 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 <re...@gmail.com>
>> > 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: batik-dev-unsubscribe@xmlgraphics.apache.org
>> >> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
Re: Mouse Interaction behavior
Posted by Renaud AUBIN <re...@gmail.com>.
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 <th...@kodak.com>:
> Hi Renaud,
>
> BTW this discussion should really take place on batik-users since it
> doesn't involve
> development of Batik.
>
> Renaud AUBIN <re...@gmail.com> 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 <jo...@gmail.com>:
>> >
>> > 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 <re...@gmail.com>
>> > 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: batik-dev-unsubscribe@xmlgraphics.apache.org
>> >> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org