Due to the fact that the points renderer does not know for sure
which attributes will be used for rendering, it is now mandatory
to provide both vertex/fragment shaders for rendering AND hit
detection.
The hit detection shaders should expect having an `a_hitColor`
that they should return to allow matching the feature uid.
This will be all one eventually by shader builders under the hood.
Now most attributes will be custom ones defined by the user of the renderer.
The hit detection is broken for now and still has to be fixed.
Also it is not possible anymore to give a texture to the renderer,
this will have to be fixed as well.
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.
Olivier Guyot
