[OpenLayers-Dev] Vector layer isFixed

[Pierre GIRAUD]

I'm not OK to consider that the Canvas demo and the WFS-T one are
similar in regard to the amount of drawn features. I think that now
the quantity of data displayed in the WFS-T demo is really important.

To my mind, there is no big advantage to convert geograhical
coordinates into pixel for SVG or VML. Both don't mind in what units
the coordinates are. The conversion would need more process to be done
and this is probably useless.

I haven't tested it in the current vector branch but I tried to set
little demo using the GoogleMap API and a modified
OpenLayers.Writer.GML code to build an application that draws the
wfs-T demo features. When creating the GPolyline features, what Google
does is to convert coordinates into pixel units to render them in SVG.
This step seems to need CPU time and to slow down the application.
Then When panning the map, the move is really slow if the amount of
draws is important.
In an other hand, each feature is rendered by a single <gml> tag. This
might be another big difference.

We probably won't find any good solution for the panning performance.
A possible one would be to hide the svg container element while
dragging the map, but this isn't clean.

Another big point was to get rid of the "isFixed" parameter for vector
layers so that they are in the mapContainer. I've modified some code
to do that. The result doesn't really affect the panning. The only
visible thing is that the features are clipped (by the dragStart map
extent) until the user stops dragging the map. At this point, the svg
container is moved back to its original position, and the extent of
the vector changed too.

I'll commit this for tests as soon as the DNS problems are settled.

Regards

Pierre

On 12/17/06, Christopher Schmidt <crschmidt at metacarta.com> wrote:
> Currently, the vector layer isFixed. This is a problem, because it means
> that in order to keep an updated drawing on the screen, the layer has to
> redraw dozens or hundreds of times when moving.
>
> In the past, we resolved this with the canvas layer by making the
> drawing window always start at 0,0 (rather than at the geometric
> location of that point), and then all drawing was done in pixel space
> from that 0,0 origin using the map.getPixelFromLonLat functions.
>
> Using the getPixelFromLonLat functionality on the map is also what
> created support for drawing on things like Google Maps, where the pixel
> -> geo space coordinates aren't uniform.
>
> It seems that the current vector code doesn't do this.
>
> I'm wondering if there's a way we can pow-wow on this and we can
> either:
>
>   1. Help me understand why it can't be done that way
>   2. Help me understand what code I need to change to help fix it.
>
> I looked at the code, and my first inclination was to look at the
> Renderer/Svg.js code. setExtent calls:
>
>  this.svgRoot.setAttributeNS(null, "viewBox",  x + " " + -y + " " + width
>                                                  + " " + height);
>
> It seems like what I want this to do is "0 0 width height" instead. This
> would then require changing the drawing functions: currently, they are:
>
> node.setAttributeNS(null, "cx", geometry.x);
>
> Instead, geometry.x would need to be calculated based on the relative
> position of the layer, and use the LonLat -> pixel conversion code.
> Paul's original Canvas layer did this with:
>
>     convertToPx: function(lonLat) {
>         if (this.vectorLayer) {
>             var px = this.vectorLayer.map.getLayerPxFromLonLat(lonLat);
>             var dX = -parseInt(this.vectorLayer.canvas.style.left);
>             var dY = -parseInt(this.vectorLayer.canvas.style.top);
>             px.x += dX;
>             px.y += dY;
>             return px;
>         }
>     }
>
> If you look at:
>
> http://dev.openlayers.org/sandbox/pagameba/vector-original/examples/vector.html
>
> You can see the difference in performance with a similar number of features
> to the current WFS-T demo. When the screen redraws, you see slow
> loading, but not when dragging.
>
> If someone who has worked on the current vector rendering code could
> look this over and let me know what they think, I'd appreciate it.
>
> Regards,
> --
> Christopher Schmidt
> MetaCarta
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>