The previous sorting criteria would sometimes allow
C > B, B > A but A > C, making the internal std::sort
code sometimes point to an invalid reference.
Fixes#7737
It should be safe to invoke GeometryTileWorker::setData multiple times without invoking GeometryTileWorker::setLayers. Therefore GeometryTileWorker::redoLayout() must not consume the layers.
Ignore empty feature collections or non–feature collections for the purposes of clustering or tiling. A source’s clustering option can only be set when the source is constructed, but setGeoJSON() enables the developer to swap a clusterable feature for an unclusterable geometry and back.
Update only when, and just prior to, rendering, giving no opportunity to interleave unexpected state changes. This means that every time anything about the state is changed, we'll have to attempt a render to reflect that change. In the case of continuous rendering this has happened before this change as well, but it leaves no room for time to pass between an update and a render. In the case of still image rendering, a render call will only actually paint something to the view when all resources have been loaded.
- Put "breakable" punctuation (such as a hyphen) on the line that starts the break, not the line after the break.
- Process all characters with the line breaking algorithm, even if we don't have glyphs for them. Some fonts have glyph-less breakable characters (we end up treating them similarly to a "zero-width space").
- Don't include trailing white space in raggedness calculations
- Make the "favor short final lines" rule more aggressive (unlike the other changes, this one is purely an aesthetic choice)
* Don't include trailing spacing (as opposed to whitespace) in lineLength
* Modify BiDi interface to require initial bidi layout and linebreaking to happen in one call.
* Code style changes suggested by @kkaefer
ported from -js: ef5582dd3bc5c15a3112e875ed66494dab8e9d0b
Project the extrusion and compare it's projected pixel length with the
actual pixel length and adjust antialiasing accordingly.
The previous approach calculated the adjustment much more indirectly and
had no intuitive explanation.
ported from -js: eb6c6596c6a7a61363d30356674e0002153b1d19
`altitude` was a terribly-named variable that was used to indirectly
control the fov. This should eliminate some confusion.
`altitude` was equivalent to `cameraToCenterDistance / height`
ported from -js: c52a09639ceeeb809cd837360993df9c45b45420
This replaces a hardcoded shader approximation with a more correct,
FOV-dependent one.
`gl_Position.w - 0.5`
is replaced with
`gl_Position.w / tan(fov)`
The `/ tan(fov)` is handled by multiplying `1 / tan(fov)` into `u_gamma`
outside the shader.
I think `- 0.5` was just chosen as something that looked right for the
default fov.lease enter the commit message for your changes. Lines starting
