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:
https://github.com/WebKit/webkit/blob/8f4765e5698c9171c2b3f984d0d9d65188185de3/Source/WebCore/platform/graphics/chromium/cc/CCRenderSurfaceFilters.cpp#L64-80
Conflicts:
src/ol/renderer/dom/domlayerrenderer.js
Telling the compiler that object keys are numeric causes more harm
than good (see === comparison that could never be met though the
compiler didn't catch it).
Never use goog functions without reading the source first. The
goog.array.sort method does nothing special sorting numeric strings
(so the zs array might be ['1', '10', '2'] here).
The render method always generates a map of all tiles that should be drawn
(called tilesToDrawByZ). This includes tiles at alternate resolutions, tiles
still loading, and tiles previously rendered. At the end of the render
sequence we can simply remove all previously rendered tiles that aren't in
tilesToDrawByZ. This provides an alternate solution to the problem described
in #53 and more.
This brings equivalent behavior when rotating in both renderers. Previously, offsets were maintained with style top/left. Now a single transform handles the translation and rotation. The scale3d function removes the separation between tiles. The next step for the DOM renderer is to scale in this same transform.
When loading this example in compiled mode, the page displays the following:
ol3 proj4js demo
[object Object][object Object]
With `mode=RAW`, it does display some numbers, but I think we could better explain this functionality with a different sort of tutorial/example.
Thanks @fredj for the inspiration. This gives us initial rotation support. It exposes some issues in the interactions that I'll address separately. Closes#22.
When zooming to a new zoom level, we can immediately remove tiles from the previous level. This (strongly) suggests not adding images to the container until they have actually loaded.
We only want to adjust things that have to do with rendering (like the position of the layers panel) when actually rendering. The handleXChange methods may be called more times than we can actually render, so we never want to do anything that touches the DOM there. Instead, we have to keep track of the state at previous render and adjust the layers panel (or other) based on changes only when rendering.
When zooming or panning, if we have tiles at alternate resolutions, those tiles are inserted in the DOM before the tiles at the target resolution. This means you should see blurry tiles instead of whitespace when panning (assuming you've already zoomed in a bit).
Tile pruning code separated into to methods for clarity. Alt-z tiles are only removed when all current-z tiles have loaded. Thanks @elemoine for the excellent debugging session.
Eventually, well have to ask renderers for all pixel and size related stuff. And the map overlay renderer will do all pixel<->loc math. For now, we let the map do this math based on its viewport - as this is where the mouse events are handled and it is pixels relative to the viewport that are being generated. For now, the getViewportPixelForLoc and getLocForViewportPixel are now more explicitly named.
Plovr checks the referrer for query string parameters (like mode), so we don't need any of this query string parsing (thanks @elemoine for the tip).
The reason we still dynamically generate the script tag is to work on other domains (e.g. testing on a VM or mobile device). In this case, we make use of the `window.location.hostname`.
Tim Schaub