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