hit detection with canvas

[tschaub]

This ticket was originally #2839, but that one has been used for other purposes. This ticket will strictly be about doing hit detection with canvas (with code from  this sandbox).

[fredj]

patch from sandbox/tschaub/canvas

[fredj]

minor coding style fixes, ready to review

[fredj]

I'd like to set hitDetection defaults to true. Otherwise it should be set at the layer level every time the select feature (or an other handler) is activated to select a feature.

Do you think this will impact the performances ?

[tschaub]

I'm making a few changes to account for changes in the trunk. Will update the patch when it is review ready.

[tschaub]

hit detection with canvas

[tschaub]

Ok, the latest patch is ready for review.

This patch contains a number of changes to the canvas renderer. The primary change is to support hit detection based on the symbolizer that features are rendered with. The additional changes are to better deal with interior rings in polygons (#2856), to avoid errors rendering geometries with NaN coordinate values (#3222), and to store constructor options on the renderer (ticket lost in the pile).

I know it makes review harder to have multiple changes in here, but the patches were developed during the development of this functionality, and they would require a fair bit more work to apply to the trunk separately.

It should also be said that this new functionality comes with some caveats:

• There is potential for false positives in hit detection. I will write this up more fully elsewhere, and we can consider a more robust solution later. For now, without many overlapping features, the chances of false positives are rare.
• When using an external graphic, hit detection is currently limited to the same origin policy. The external graphic hit detection is likely overly functional, and it could be simplified to do hit detection in a rect representing the rendered image (currently it respects transparency in graphics). This enhancement would come with a performance gain and would get around the same origin policy.

I'll ticket these issues separately.

Thanks for any review.

[fredj]

Two minor comment issues:

• hitDetection comment: change "Default is false" to "Default is true"
• getFeatureIdFromEvent comment: the function returns a feature, not a feature id.

In getFeatureIdFromEvent, is there a reason that a bitwise or (|) is used instead of a logical or () ?

Thanks Tim for this patch

[fredj]

comments fix, use logical or instead of bitwise or

[fredj]

3207.2.patch fixed the two comments and replace bitwise or with logical or.

Please commit if my changes are ok to you.

[tschaub]

Thanks for the review.

Replying to fredj:

Two minor comment issues: * hitDetection comment: change "Default is false" to "Default is true"

Will change.

* getFeatureIdFromEvent comment: the function returns a feature, not a feature id.

Will change.

In getFeatureIdFromEvent, is there a reason that a bitwise or (|) is used instead of a logical or () ?

A bitwise | truncates a number to an integer. A logical is not what is wanted here.

Thanks Tim for this patch

[tschaub]

(In [11849]) Adding in support for hit detection with canvas (and rendering holes in polygons). r=fredj (closes #3207)