RT-20302: Consider changing picking behavior of dashed strokes
Dr. Michael Paus
mp at jugs.org
Thu May 10 06:44:54 PDT 2012
Am 10.05.2012 15:33, schrieb Lubomir Nerad:
> Hi Michael,
> 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).
Maybe this should be documented somewhere.
> 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 beneficial.
>> 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?
Ok, under these circumstances you are probably right.
>> 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.
Yes, that was also my conclusion but this needs further support in
JavaFX for geometric picking.
> 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.
That would be great but I would already be happy if you could provide
the functionality which I have provided in the two methods attached to
>> 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 stokes.
>>> Do you agree?
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.
More information about the openjfx-dev