When the dom renderer included logic to stretch tiles so that gaps were properly filled for fractional zoom levels, we needed to take this into account when getting a tile coordinate for a given coordinate and resolution. This was never the proper logic for a renderer that wasn't stretching occassional tiles (e.g. the WebGL renderer, the Canvas renderer, or the new DOM renderer).
Previously, the findInterimTiles method was returning undefined if the min x/y coord for a tile range was already in the lookup. The return says it indicates whether all tiles for the given z are loaded. This change corrects the return.
This change also reveals a misunderstanding of the tile range returned by `getTileRangeForExtentAndZ`. The previous findInterimTiles method was treating max values as inclusive. This is intuitive. It looks like the method returns a range where max values are exclusive.
With this commit test files provide namespaces (using goog.provide). This fixes the issue reported by @bartvde where goog objects cannot be used in Jasmine "describe" functions. It also frees us from having to add script tags for the test files in test/ol.html.
The `window.location.search` string includes the "?" symbol. Without this change, `createFromQueryData` only works if the "renderer" parameter is not in first position (see 4037bafc45).
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 rather large commit refactors the build system to solve a number of
problems:
- Object literal types are now declared in just one place
- There are no more circular dependencies
- There is no need for concealed subclasses in build-standalone mode
When building in standalone mode, you need to include the source in
build/src/external. This declares object literal types as externs so
that their properties are not renamed.
When building with the application, you need to include the source in
build/src/internal. This declares object literal types as typedefs so
that their properties can be renamed and removed.
Note also that ol.MapOptions has been merged into ol.Map, with some
renaming.
