Canvas Renderer

Attached is a patch for a Canvas renderer. It has been tested in Safari 3.1, FF2, and Opera 9.5 on Mac.

It implements feature selection by looping over its internal list of features, and doing intersection queries. Depending on the browser, this may or may not be reasonable. One thing that this behavior suggests is that the standard Feature Handler should perhaps be informed whether it is being used as a 'hover' handler: if it isn't, it shouldn't bother doing the (now somewhat expensive) getFeatureIdFromEvent check on mousemove as it currently does.

For browsing somewhat static vector data, this Renderer is quite effective, especially for browsers where SVG support is less fast: FF2, for example, gets to be much more usable on whole-world country borders maps that are currently being tossed about.

Includes support for stroke/fill width/color/opacity, externalGraphic, point/line/linearring/polygon and collections thereof.

Other than the Renderer itself, only one small change was made to the code: the Vector Layer now sets 'locked' on the renderer to indicate that there are more operations coming up, and that if the Renderer has the ability to 'delay' redrawing, it should do so. I don't know if 'locked' is the right keyword for this, but it seemed to make sense.

I'm certain that this is something Paul is very interested in. One year and a half ago, he wrote the first OL vector renderer and it was with canvas.

One important thing I first noticed is that panning seem much smoother in the canvas example. Thanks Chris for this great job.

For the record, I wrote OpenLayers.Layer.Canvas (which was vector-ish) before Paul started his vector work ... ;)

very cool! I think this is a great addition, it works well for me in ffox2 and safari 3 on mac.

Is there anything missing, or is it close to being ready for review?

Would there be any benefit to creating a Tile sub-class with Canvas to render vectors into 'tiles'?

It needs tests, and the patch should probably include something like the choropleth example I stuck in the sandbox. Also, I think my changes to the vector layer could use some further discussion before they become 'final': at the very least, they need docs on the base Renderer class, and it's possible that I've only implemented half of what we need.

Also, using the SelectControl feature with this is essentially unusable with any large-sized non-point layers at the moment due to the intersection-test on mousemove even when 'hover' is false. I think that's worth at least thinking about before we go any farther: Obviously, it liiiimits you such that you can't do 'hover: true' with large geometry sets, but you should still be able to do a click-based selectfeature control without too much trouble if we make it so that the feature handler isn't constantly looking to find intersecting geoms even when it doesn't need to.

To your tile question, I'm pretty sure the answer is 'no'. Tiles are a request mechanism: Layer.WFS could be (and has been, by users) updated to use Tiles (alternatively, we can implement this in the new Protocol handling that we're bandying about for 2.7 instead): the Renderer doesn't need to work in tiles...

Though I can sort of see the benefit, I guess: if there are 'tiles', then you only have to redraw that tile, not the whole view. Hm. I don't think it would need to be implemented as a tile subclass, in any case: I think that the Canvvas Renderer could do this as an optimization if we wanted it to.

Also of note: this doesn't help IE at all, which is where vectors are the slowest anyway, so anyone who needs to actively support IE is going to have to play "lowest common denominator" with IE anyway. (IECanvas is just a wrapper on VML -- a Canvas Renderer on top of a VML wrapper seems likely to be less effective than a VML Renderer directly.) It should be possible to do an image renderer in a similar way (with a PIL-backed image drawing server or something like that) to accomodate for IE's deficiencies in this regard.

Also, need to run it in IE, and make sure that the 'supported()' test on the canvas renderer doesn't cause errors, and make sure that I didn't leave extra ,s in, etc. I'm sure *something* I did will break IE.

Tests pass in FFox, Safari, are skipped in IE. WFS Reprojection example is changed to demonstrate functionality. Minor changes to Layer.Vector, and new Renderer added.

I've taken a look and confirmed that this works nicely in Safari and Firefox, and the tests pass. It doesn't look like you've addressed some of your previous concerns (comment 6 above), which I think is fine for an initial implementation - if it gets used then issues will crop up (or not) and can be addressed at that time.

The implementation looks good, although I don't know enough about the internals of the Renderer architecture to tell if anything significant is missing - if you are concerned about this then one of the camptocamp guys should take a look, otherwise I think it is ready to commit with a couple of very minor comments:

* It looks like the getResolution function defined in the Canvas renderer is a dup of the base class getResolution and shouldn't be needed?

* jslint reveals missing semi-colons (line 175 and 240)

Paul:

Thanks for the feedback. I addressed the Layer.Vector 'locked' thing in code, and I'm pretty happy with it. A brief conversation with Erik didn't throw up any red flags. As for the SelectFeature control, you're right: I discussed with Tim and then forgot to do anything about it. That's now #1655, thanks.

I'm uploading a new patch which removes the unneccesary getResolution and fixes the jslint errors. I think Erik still wanted to glance at this; if he gets a chance early next week, I'll let him, and otherwise I'll commit this.

Thanks again for the feedback.

In lib/OpenLayers/Renderer/Canvas.js container, extent, size, resolution and map properties are defined but these properties are already defined in parent class (OpenLayers.Renderer).

They can be removed (unless I miss something else ...)

Yep, more sideeffects of starting by copying Renderer.js. Thanks. New patch attached.

Chris, you forget the 'map' property.

The 'locked' attribut could also be use by the SVG renderer to ask the browser to suspend the redraw of the svg element. See (1), the functions are 'suspendRedraw' and 'unsuspendRedraw' but I don't know if it will speed up the rendering.

(1) http://www.w3.org/TR/2001/REC-SVG-20010904/struct.html#InterfaceSVGSVGElement

already enough reviews of this, don't need another pig in the kitchen.

(In [7862]) Add support for a Canvas renderer. This renderer will allow for some new capabilties in OpenLayers Vector drawing, including:

• Vector support for iPhone, Safari 2.x series browsers
• Improved performance of dragging the map with a large number of geometries.

The Vector layer default renderer order is now SVG, VML, Canvas, so browsers with Canvas support and no SVG or VML will be able to draw vectors.

The Canvas layer has a number of limitations: getFeatureFromEvent is much slower than the other types of layer, and any change to any feature requires a redraw of the entire canvas. Because Canvas is typically a pretty fast drawing implementation, the latter is less problematic than it might otherwise be.

r=pagameba,fred, with glances from a couple other people. (Closes #1512)