The `goog.dom.ViewportSizeMonitor` (used in map.js) creates a global leak by setting `goog.UID_PROPERTY_` on the monitored window. In order to test that we don't have other global leaks, we preemptively set the property so Mocha can compare the global before and after our tests.
The original decision to avoid index.html was because it only works with a build step. Since we've all accepted a build step, the more sensible name is index.html. Without this change, every hosted example has a link to http://openlayers.github.com/ol3/master/examples/example-list.html which 404s.
The previous logic assumed that if there were any tiles to render, the dirty state should be false. The correct logic is to say that if we don't render during animation, dirty is true.
The addFeatures method on layer is going to go away temporarily (so all feature adding will take advantage of shared vertices structures). Later we can accept feature arrays in parseFeatures and rename the method back to addFeatures.
The color names are more intuitive. And if we want to support pattern strokes or fills, we'll need additional proerties to represent other pattern properties.
We need a more flexible event system. We could have a VectorLayerEvent type and dispatch 'featuresadded' here. But listeners want features typically and perhaps extent. This won't be true for all vector layer events (suggesting a more specific VectorFeatureEvent type or something).
Previously, a lookup object containing start indexes was also used. This allowed us to remove arrays of vertices and properly update the start indexes for remaining coordinate values. In order to provide callers with stable identifiers and to work with arrays of integers alone, we cannot support a remove method. I think this is worth revisiting. Even if the array length cannot be changed in WebGL, we don't need to also impose the restriction outside. Instead, the WebGL renderer could be notified when array sizes change and update itself accordingly. I think there is more value in providing geometries with stable identifiers.
This common structure is used to store vertices for all geometry types. A slight optimization could be made by creating yet another structure to store point vertices - since these don't need to have a counts array (always 1). Creating a new structure would mean saving memory at the expense of more lib code to transport. The coordinate value lookups are not negatively impacted by using the same structure for points and higher order geometries. Since the first change above goes against my instincts, I'm not making this second change (to add another structure for shared point vertices).
Parsers that read features from strings, objects, or dom elements should implement the right interface. Among the read options is a callback that gets called after feature construction and before geometry construction. This callback is called with the feature and the geometry type and returns a shared vertices structure. The geometry is then constructed with this shared vertices structure before being added to the feature.
Instead of working with ol.Coordinate instances, transform functions work with arrays. This is in anticipation of using transform functions to transform large arrays of vertex coordinate values. The ol.projection.transform and ol.projection.transformWithCodes are slightly more convenient functions for dealing with ol.Coordinate instances. Whether we make this more consistent with the use of functions returned by ol.projection.getTransform is up for discussion.
Its not clear that we will be able to leverage the Float64Array. It may also be that the overhead of constructing these small arrays negates any benefit of faster access. And for all coordinate arrays, we'll need arrays that grow/shrink.
The first set geometry is considered the default. As an added bonus, we're back to a single argument constructor. Later, we could allow a schema to be set. This would be done before setting values (calling constructor with no args).
Tim Schaub