Make sure the object structure returned is not mangled by Closure
Do not use closure XHR or JSON in the example
Use Jasmine's async support in the test cases
Get rid of some backwards compatibility now that we have a fresh start
This commit adds several features:
- rename of class to better reflect its behaviour
- full ol.Object support
- integration with postrender event for integration with animations and
render loop
- minimised DOM modifications
- more precise positioning
- element placed in DIV to avoid modifications to user-supplied element
- correctly handle changes to the positioning property
Previously, the TiledWMS source generated a resolutions array
derived from the world extent in meters, to match the default
Web Mercator resolutions of the map. This wouldn't work for
projections with distance units different than meters. It is
better to commit to a default resolutions array where zoom level
0 is the validity extent of the projection (not the Web Mercator
world extent!) at a 256 pixel tile size.
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
