The following functions are renamed:
getTransform -> getTransformForProjections
getTransformFromCodes -> getTransform
transform -> transformWithProjections
transformWithCodes -> transform
With this change, the faster functions that avoid projection look-up
have longer names and are used internally, whereas the slower but
friendlier short name functions are available for users.
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:
https://github.com/WebKit/webkit/blob/8f4765e5698c9171c2b3f984d0d9d65188185de3/Source/WebCore/platform/graphics/chromium/cc/CCRenderSurfaceFilters.cpp#L64-80
Conflicts:
src/ol/renderer/dom/domlayerrenderer.js
Tim Schaub
Andreas Hocevar
Peter Robins
Tom Payne
Frederic Junod
Bart van den Eijnden
Éric Lemoine
Bruno Binet
Éric Lemoine