RT-20302: Consider changing picking behavior of dashed strokes

[Dr. Michael Paus]

Hi Lubo

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:
>> 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.
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 
RT-20452.
>
>> 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
>>>
>>
>>


-- 
--------------------------------------------------------------------------------------
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.