Requirement of cross-origin isolated

[maxammann]

maplibre-rs currently requires that the host site, which runs maplibre-rs needs to be "corss-origin isolated". This is a quite strict requirement: https://web.dev/coop-coep/

The reason for this requirement is the usage of SharedArrayBuffer. I see three possible solutions for this problem:

• Provide an alternative implementation for "multi-threading" on the web. This would complicate the asynchronous capabilities of maplibre-rs even more. This also introduces a performance penalty because computed data needs to be serialized in order to pass it between WebWorkers
• Hope that the restrictions for SharedArrayBuffer are lowered in the next 2 years.
• Live with that fact. This is probably not really possible. Enabling "cross-origin isolation" has an impact on any cross-origin resources used by users.

More Info: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes

[maxammann]

There are apparently discussions about removing the restrictions for SharedArrayBuffer:

May 6, 2021: Based on feedback and issues reported we've decided to adjust the timeline for SharedArrayBuffer usage in none cross-origin isolated sites to be restricted in Chrome M92.

https://web.dev/coop-coep/

[maxammann]

Minor relaxation: https://github.com/WICG/credentiallessness

[maxammann]

related: whatwg/html#6364

[bchapuis]

Provide an alternative implementation for "multi-threading" on the web. This would complicate the asynchronous capabilities of maplibre-rs even more. This also introduces a performance penalty because computed data needs to be serialized in order to pass it between WebWorkers

Does this correspond to what MapLibre JS and Cesium JS are doing with WebWorkers? If I recall correctly, the serialisation problem is the same in JS, therefore, I wouldn't worry too much about the performance penalty. The main difficulty is probably to come up with an understandable design.

[maxammann]

Actually there is no serialisation is required. postMessage supports ArrayBuffer actually: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm

So the only difference is that with the current method we can use the same sync primitives like on non-web platforms.

[maxammann]

I drafted a first idea: #79

[bchapuis]

If I understand correctly the issue and the documentation the WebWorkers must be started using javascript. This makes it hard to devise an elegant solution for both the Web and the native targets. Is that right? In this context, I was wondering if describing all the tasks that need to be parallelized may help at finding a solution.

[maxammann]

Yes, we need code which starts the webworkers, that is already done in the web crate.
When we use cross-origin isolation then we can use all the goodies from Rust without any additional changes. We can use Mutexes, Barriers, MPSC channels etc.

When we do not enforce cross-origin isolation then we loos all of that and have to use the postMessage APIs for synchronisation. That is possible with minimum performance overhead, but makes the code more complicated.

[maxammann]

Seems like bevy has the same problem (obviously): bevyengine/bevy#4078