On 4/1/11 2:30 AM, Andreas Hocevar wrote:
Hey Tim,

Renderer.SVG returns null from drawFeature when a feature was not completely 
rendered (i.e. clipped somewhere to not exceed the maximum coordinate value). 
This is missing in the Renderer::drawFeature API docs. So if we could get rid 
of Renderer.SVG and replace it with Renderer.SVG2, we could change Layer.Vector 
so it only adds features to the unrenderedFeatures array when 
Renderer.DrawFeature returns false. Right now, we should check for === false || 
=== null.

I created http://trac.osgeo.org/openlayers/ticket/3235 for this. Patch to come.

Thanks for the explanation (and the fix).

Tim


Andreas.


On Apr 1, 2011, at 00:39 , Tim Schaub wrote:

It looks like since r7930 we've been expecting renderers to return truthy 
values for features that actually get rendered.

http://trac.osgeo.org/openlayers/changeset/7930

The canvas renderer missed this change.

http://trac.osgeo.org/openlayers/browser/trunk/openlayers/lib/OpenLayers/Renderer/Canvas.js?rev=7930

So, unless I'm misreading, for the past 2.5 years we've been doing an 
unnecessary drawFeature call for every feature on every pan in the canvas 
renderer.

Volker Grabsch just put up a patch on a ticket so that we always return true in 
the canvas renderer's drawFeature method.  I committed a variant of that patch 
so the method acts more like the other renderers.

http://trac.osgeo.org/openlayers/changeset/11851

To be consistent with the NG renderer, the canvas renderer returns undefined if 
the feature has no geometry.  I see there are other tickets about dealing with 
features outside the extent of the viewport, and I assume these would result in 
a false return.

I'm unclear why there needs to be a difference in the return here.  The vector 
layer only checks if the return is falsey.  I'm not sure if there are any other 
custom renderers out there, but it would be safer in my opinion to check for 
=== false in the vector layer.

Does anybody know if the difference in the returns is significant here?

Thanks,
Tim


--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev





--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev

Reply via email to