Add GlRenderer and DOMRenderer about mapillary-js

[oscarlorentzon]

Agree on having one renderer for DOM and one for GL. The diagram seems simplified though. This is what I see when reading the proposal.

                                    +---------------+
                                    |               |
                                    | State Context |
                                    |               |
                                    +-------+-------+
                                            |
                          +-----------------+------------------+
                          | a               |                  | b
                          v                 |                  v
                    +----------+            |             +----------+
                    |          |            |             |          |
                    |   UI 1   |            | c           |   UI 2   |
                    |          |            |             |          |
                    +-----+----+            |             +----+-----+
                          |                 |                  |  
                Push data | d               |        Push data | e
                          +-----------------+------------------+
                                            |
                                            v
                                   +-----------------+
                                   |                 |
                                   |    Renderer     |
                                   |                 |
                                   +-----------------+

Renderer could be either the DOMRenderer or GLRenderer because they are equivalent, they both require all state updates to get the current camera. We can only have one class instance requesting animation frames in the lib. Therefore it can’t be related to either of the renderers but needs to live somewhere else, e.g. somewhere close to state as in the diagram.

With this setup both of the UIs as well as the Renderer needs to subscribe to the current state observable (a, b and c). Pushing data to a service for the Renderer to render seems to be prone to race conditions and seems to introduce difficulties in determining if all UIs are done processing the state. The rendering would depend on the order of arrival of c, d and e.

Also the renderer can’t be aware of how to perform multistage rendering like in the current GLUI https://github.com/mapillary/mapillary-js/blob/master/src/ui/GlUI/GlUI.ts#L146 , only the UI itself can know this and therefor pushing just data for the Renderer to render is not enough. This will be more complicated with more UIs pushing.

For each frame loop two stages are generally run - the update stage where things are updated and the render stage where things are rendered. The render stage is only done if the update stage determines if there is a need to render. Another conceptual view on the new structure is the following.

                                    +---------------+
                                    |               |
                                    | State Context |
                                    |               |
                                    +-------+-------+
                                            |
                                            | a
                                            v
                                   +-----------------+
                                   |                 |
                                   |    Renderer     |
                                   |                 |
                                   +-----------------+
                                            ^
                                            |
                          +-----------------+-------------------+
                          | b                                   | c
                    +-----+----+                          +-----+----+
                    |          |                          |          |
                    |   UI 1   |                          |   UI 2   |
                    |          |                          |          |
                    +-----+----+                          +----+-----+

Here the Renderer subscribes to the current state observable (a). The UIs register callbacks (b and c) to the Renderer. In the case of the GLRenderer this could be two callbacks - an animate/update callback, which takes the state and returns a boolean indicating if this UI needs rendering, as well as a render callback. The animate callbacks are always run before the rendering callbacks. The actual rendering is performed if any of the UIs determine it needs to render.

Irrespective of the architecture the GLRenderer itself needs to know when to clear, when to clear depth and possibly more things. The GLUIs needs to indicate if they are background objects or foreground objects and the rendering must take this into account when determining the order to render scenes/invoke render callbacks.

[oscarlorentzon]

A GLRenderer has been implemented and its API is enough for now. The architecture in the top image in the previous post has been used.

Modifications/additions will need to be done when raytracing is required for GL UIs.