RT-20302: Consider changing picking behavior of dashed strokes

[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). 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?

> 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:
> http://javafx-jira.kenai.com/browse/RT-20452
>

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.

> Michael
>

Thanks,
Lubo

>
> Am 09.05.2012 17:44, schrieb Lubomir Nerad:
>> Hi,
>>
>> 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?
>>
>> Thanks,
>> Lubo
>>
>
>