The map does not fire ol.render.Event#render. Change events are
now only listed for classes that fire them, and a description
about when they are fired is added.
We no longer add observable annotations to the constructor.
Instead, we just mark getters (and for read/write properties
also setters) with an observable annotation.
This change adds a stability value to the api annotation, with
'experimental' as default value.
enum, typedef and event annotations are never exportable, but
api annotations are needed there to make them appear in the
docs.
Nested typedefs are no longer inlined recursively, because the
resulting tables get too wide with the current template.
This commit simplifies the exports.js plugin so it only relies
on the stability notes to generate the documentation, which
completely decouples it from the exportable API.
As a rule of thumb, whenever something has an 'api' annotation,
it should also have a 'stability' annotation. A more verbose
documentation of ol3 specific annotation usage is available in
the new 'apidoc/readme.md' file.
This commit also modifies all source files to implement these
usage suggestions.
This PR adds documentation for observable properties, which will then be pulled into the docs correctly once #1180 is merged. This is a first pass based on searching for definition of observable properties being defined as enums after lines ending with `Property = {`. If there are observable properties implemented that don't follow this pattern then they are not included.
I've added simple descriptions based on what I know or could easily figure out, there may be some properties (like preload) that are not correctly described.
I've also added `readonly` annotations where I knew that a property was readonly. I may have missed some readonly properties.
ol.layer.Base has a bunch of properties but I don't think it is exported so the documentation of these properties will not show up, so I added the documentation to ol.layer.Layer instead even though this isn't really where it should be documented.
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
