RT-20302: Consider changing picking behavior of dashed strokes
lubomir.nerad at oracle.com
Thu May 10 06:33:34 PDT 2012
On 5/9/2012 6:54 PM, Dr. Michael Paus wrote:
> It is in general always a good idea to keep things consistent but one
> also has to keep in mind
> performance and the potential use-cases. So, how do you expect the
> picking performance to be
> affected by this change?
This depends on how these dashed strokes are used in the scene. If they
are used as decorations only, then the performance impact is zero
(assuming the shapes which use them have mouse transparent properties
set to true or the stroke types set to inside with non-null fills). If
not, then the performance impact of this change on such objects will be
negative. I assume that most of the time dashed strokes will fall in the
first (decorations only) category. For usages which fall in the second
category, it seems to me that the increased picking "accuracy" should be
> Concerning use-cases. What is the expectation of a user? I have to admit
> that I would probably be surprised if I could not pick/select say a
> circle at some point of its
> obvious border only because the border happens to be dashed instead of
> being solid.
What if you allow to zoom your scene and it is zoomed to the level when
the dashes and spaces occupy large areas with another objects under
them. It would be strange then to pick spaces instead of the objects
under them, or not?
> Finally it all depends on how you want picking to behave in general.
> Is it a geometrical
> operation of a graphical operation. It's a pity that JavaFX does not
> offer us any choice
> here, because for some use-cases a geometrical interpretation, which
> is independent of
> the graphical appearance of a shape, is much better suited as I have
> outlined here:
For the use cases you describe in RT-20452, it seems to me that it would
be better to leave picking to the application. What I mean is that FX
can handle picking for classical UI components and the "map" view node
(to the extend that it is a rectangular area). Then when mouse events
are delivered to the map view, the map view will choose what of its
subnodes to highlight, select, execute actions for, etc. We can probably
help such applications with providing some framework for geometry
definition, manipulation and calculations and ensure its
interoperability with the existing FX Shape(Node) classes.
> Am 09.05.2012 17:44, schrieb Lubomir Nerad:
>> I would like to change mouse picking behavior of objects with dashed
>> stroke as described in http://javafx-jira.kenai.com/browse/RT-20302.
>> Currently an object is picked even when the mouse click happens in
>> the non-filled parts (inside spaces) of the dashed stroke (stroke
>> dash array and dash offset have no impact on picking). With RT-19994,
>> this can create an unexpected situation, when a Shape is picked
>> inside stroke spaces, but if it is used in a CAG operation (for
>> example Shape.intersect(shape1, shape1)) the resulting Shape won't
>> include the spaces and so won't be picked inside of them. To get
>> consistent behavior I propose not to pick the spaces inside object
>> Do you agree?
More information about the openjfx-dev