This commit is a cherry-pick of 19f7778.
The current draft of the [filter spec](https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html)
describes brightness, contrast, hue-rotate, and saturate functions that
roughly match our layer's setBrightness, setContrast, setHue, and
setSaturation methods. These changes make the range of our methods match
the corresponding functions in the spec. The one exception is the
brightness function. The spec says it has a range of 0 to positive infinity.
The WebKit implementation accepts a range of -1 to 1 (as of
https://github.com/WebKit/webkit/commit/8f4765e569). There's an open
(ticket)[https://www.w3.org/Bugs/Public/show_bug.cgi?id=15647] recommending
that the spec be changed to match.
I'm not stuck on having our methods match those of the filter spec, but the
parity would be nice.
These changes leave the WebGL map renderer "broken" (whacky colors). It would
be straightforward to update the current fragment shader to handle the new
range of hue, but the brightness, contrast, and saturation handling will
need to be reworked.
For inspiration, here are the color transformation
matrix calculations the WebKit filters:
8f4765e569/Source/WebCore/platform/graphics/chromium/cc/CCRenderSurfaceFilters.cpp (L64-80)
Conflicts:
src/ol/renderer/dom/domlayerrenderer.js
This fixes an issue easily reproducible in the side-by-side example where the DOM renderer is not notified when tiles loaded by the WebGL renderer have been received.
A port of f46cdb4 to the current master. The tilelayer renderer can be simplified a bit by waiting to append tiles to the dom until they have loaded. Refs #84 and #33.
* The Map's private createProjection_ method is now a public
method of the Projection. It is also used by TiledWMSSource
to calculate the appropriate projection from the user
configuration.
* ol.Projection.addProjection now adds the transformation for
the source == target case. This makes it easy for the user
to create custom projection maps without including proj4js and
without adding a custom transformation, as long as the
userProjection equals the projection.
* The TiledWMSSource now uses the same default resolutions as
the map (i.e. the OSM resolutions)
* The modulo calculation for wrapping extents now works for all
grid configurations, by not calculating the number of columns
based on an assumption about the way the zoom levels relate to
resolutions.
* The wms-custom-proj example now shows how to properly
configure a custom resolution, i.e. by using the validity
extent of the projection as its extent.
Setting the extent on a tile source now only means that tiles
won't be drawn outside that extent. Now the only way to specify
the origin of the tile grid is to provide a custom tileGrid. By
default, the grid origin is the top left corner of the
projection's extent.
The WMS used in the example does not send CORS headers (I think
not many WMS services do). It seems that the WebGL renderer
needs script access to the image data, so the example only works
with the DOM renderer in Firefox.
This ensures that maps with WMS layers with different extents
do not scale the tiles differently for each layer when the
default tileGrid is used. Note that it is always possible to
configure WMS sources with a custom tileGrid.
