The worker self object is simply cast to any to make sure typescript
does not complain.
Actual typecheck may be restored once the following issue is fixed:
https://github.com/microsoft/TypeScript/issues/20595
Now two methods are available: `readAll` and `readPixel`,
and the data from the render target is not re-read every time unless
`clearCachedData` is called.
For now only `forEachFeatureAtCoordinate` is implemented.
Each time the viewport is rendered, another similar render pass is
done using the specific hit detection instructions. Feature uid's are
encoded in the r,g,b,a channels and can then be decoded on the fly.
Note: the `readPixels` operation is taking a lot of time,
around 10-20ms each frame.
Hit detection is done by rendering features with their id encoded in the
color attribute. A parallel set of render instructions and a second
vertex buffer is used specifically for that.
Previously features were indexed by uid only when they
did not have a defined id.
A new method was added: `getFeatureByUid`. This is not part of
the public API.
This will facilitate the lookup of features for hit detection.
The worker currently works by receiving GENERATE_BUFFERS messages and
will send back the same kind of message, with the generated buffers
attached. All properties of the original message are kept, so that
when a GENERATE_BUFFERS message comes back to the main thread it
is possible to know what and how the buffers where generated.
This is typically used for the `projectionTransform` matrix, and
will also be necessary when working with tiles.
The worker receives a transferable array of instructions
and sends back two transferable arrays (vertex and index buffer).
The projection transform is also sent so that when the main thread
receives the buffers from the worker it also knows which projection to
apply when rendering the geometries.
The base webgl renderer module now has two types of utilities:
* `writeXFeatureInstructions` will write a series of values in a given
typed array, which represent how a given feature will be rendered; for points,
this means position, size, color, etc.
* `writeXFeatureToBuffers` will fill up the given index & vertex buffers
with values based on the provided render instructions
As such, the logic for rendering features is:
user-input style > instructions array >(*) index/vertex buffers > draw
(*) this transformation is intended to be done on a worker.
...in the collection.
Previously two features with the same id could be pushed manually in the
features collection and stay there.
This would cause an error when clearing the source.
Fixes#6183.
The `WebGLHelper` class now provides a `makeProjectionTransform` method
that updates a transform to match the projection for a given frame state.
This also means that the WebGLHelper does not set the projection matrix
uniform anymore, this is the responsibility of the renderer as
the rendered coordinates will not be in world space from now on.
This uses an undocumented method to trigger a synchronous redraw
instead of using the standard schedule from Mapbox. The CSS previously used
to make the OL and MB views match is not necessary anymore.
Reference: https://github.com/mapbox/mapbox-gl-js/issues/7893#issue-408992184
The transpiling step is done by babel instead of bublé now.
Bublé caused the istanbul instrumenter step to crash because of an
unexpected SourceMap object format.
Previously, an interaction could begin while target values
(center/resolution) were out of the allowed range, causing a
glitch where the view zoom/position would jump suddenly.
By default, alpha premultiplying should be done by the initial rendering
(eg quads) and not the final post processing pass.
The default post processing pass expects premultiplied color values and
will not do this operation itself.
This also makes it possible to call `solveConstraints_` with a duration of 0,
which means the target values are modified straight away without triggering
an animation or leaving the current flow.
Previously the formula for the resolution constraint allowed going way past
the minimum zoom.
Also adjusted the center constraint to avoid a zigzag effect when going out
of resolution bounds.
The DragPan, KeyboardPan and DragZoom interactions now make sure to
animate to a valid center/resolution target to avoid
a chained "resolve" animation which looks weird.
The `View.fit` method was also fixed to use this.
API changes:
* (breaking) the `rotate` method is gone
* the `adjustRotation`, `adjustResolution` and `adjustZoom` methods are now
available and allow using an anchor.
This means interactions do not have to do the anchor computation themselves
and this also fix anchor computation when constraints must be applied.
This introduces a breaking change.
This options replaces the various `constrainResolution` options on interactions
and the `fit` method.
Since constraints are now the responsibility of the View, the fact that intermediary
zoom levels are allowed or not is now set in the view options.
By default, the view resolution is unconstrained.
This will help making sure that the view will come back to a "rested" state
once the interactions are over.
Interactions no longer need to handle the animation back to a rested state,
they simply call `endInteraction` with the desired duration and direction.
This commit aims to simplify the computation of zoom and resolution in the
View class.
Previously zoom levels and resolution computations were mixed in different places,
ie resolution constraints, initial values, etc.
Now the View class only has the `getZoomForResolution` and `getResolutionForZoom`
methods to convert from one system to another.
Other than that, most computations use the resolution system internally.
The `constrainResolution` method also does not exist anymore, and is replaced
by `getValidResolution` and `getValidZoomLevel` public methods.
This introduces a breaking change:
The `extent` view option now constrains the whole viewport and not just the
view center.
The option `constrainOnlyCenter` was added to keep the previous behaviour.
Constraining the whole viewport and not only the view center means
that the center and resolution constraints must be applied with a knowledge of
the viewport size.
The `getValidZoomLevel` apply the current resolution constraint to return
a value that is guaranteed valid.
This is used for interactions & controls which need a target value to work:
the +/- buttons, the zoom clider, the dragbox zoom and the mouse wheel zoom.
The view now has targetCenter, targetRotation and targetResolution members.
These hold the new values given by set* methods. The actual view parameters are then changed by
calling `applyParameters_`.
Things done:
- stay closer to the original rendering in canvas
- get rid of the intermediary blur step
- use the new callbacks in the webgl points renderer
- premultiply alpha in the last postprocessing step
Olivier Guyot
