Thanks for the follow-up, Chris.

We are closing this issue for now. If you think of some generalized suggestion that fits a useful built-in feature in the future, do let us know.

Regards,
Dimo
Progress Telerik

Hi Chris,

By custom implementation regarding this:

"Custom implementation is fine, assuming the control supports such a thing.  I didn't get that impression from reading the docs."

I meant that such a layer can be built by a custom renderer outside of the Map component - imagine that you are rendering some span/div elements that display the data from the IOT devices. Rendering arbitrary data on top of the Map in a separate layer is not something that is supported out of the box as all the currently available layer types serve a particular purpose - they render images of geo data, markers, specific shapes on top (shape/bubble layer), etc. Still, you can build a custom layer that is displayed on top of the map that makes it look as it is part of the map to the end-user.

"If we use SVG as our rendering engine instead of SkiaSharp, does that give us any benefits? (besides Blazor Server support which I do understand)."

Using SVG or other technology (e.g. canvas) depends on your requirements and what exactly should be achieved as SVG and Canvas can both display the same thing, but provide different features on top. As far as I can understand from the screenshot, the data that is displayed over the map can be rendered using HTML as well, whereas the rich graphics on the right side are more appropriate for SVG/canvas rendering.

As for performance - various approaches can yield different results, so a good strategy is to test whether something meets your requirements for interactivity or not (seems you have done this already) - if SkiaSharp renders what you want in 50ms, but there is a technology that does this 4-5 times faster, it might not actually matter if it is 50ms or 10ms as most probably it will not be that critical. On the other hand, if something is rendered in 5s compared to 1s, then this will have a lot more impact. Regarding unmarshalled calls - yes, if you are 100% sure that you need to work in wasm apps only, then using unmarshalled JSIntrop is something that can be leveraged as it is supposed to perform better.

Regards,
Stamo Gochev
Progress Telerik

Hi,

You can find more information regarding the list of questions below, but it will be very helpful if you can provide more details regarding the bigger scenario that you want to handle. Doing this before we go into the technical aspects of how this can be achieved using the Map component will be preferable as it will allow working in a better context. For example, can you send me a short video and/or screenshots of the final result that you want to achieve, so that I can evaluate which approach best suits the concrete expectations?

What I can say for now is that rendering such a "new layer type" on top of the Map is more appropriate for a custom implementation, which will allow handling specific needs of the app.

Regarding technical details - the Map currently has 2 rendering approaches - HTML for the tile layers (as well as marker layers) and SVG for the shape/bubble layers. Canvas rendering is not strictly impossible, but it is not that good for interactions compared to HTML+SVG elements. In addition, the approach that SkiaSharp provides works for Blazor WASM apps only, but we need to support both server-side and wasm apps, so having a feature that works for just one of the Blazor app types is not acceptable at the current moment. Moreover, there are alternative ways to SkiaSharp that provide drawing capabilities that are not restricted to wasm only.

Here is more information on the list of questions from your post:

"1. The Image is a layer rendered on top of the map viewport (as opposed to the entire map canvas)"

This can be implemented by rendering div/span elements and positioning them on top of the map. Rendering a canvas tag on top will prevent the built-in interactions of the map, but displaying specific elements (e.g. imagine the current markers) is more flexible and will not prevent the basic functionalities of the component.

"2. The Image layer can know the size of the ViewPort so it can create an identical size image (or perhaps this is handled automatically by the Map control)"

This is not handled automatically, but the width/height of the map are configured by the developer anywa, so the dimensions are known. If further customizations are necessary, the calculated width/height can be obtained.

"3. The Image layer can be re-rendered as often as the customer code desires (we're showing realtime data on top of maps, so we will want to re-render the Image layer say every 250ms."

Depending on the implementation, the rendering performance of the layer can be optimized in order to work with real-time updates that can occur very often.

"4. When the map viewport changes (pan, zoom, etc.), events are fired so the Image layer customer code can re-render the image based on the new viewport coordinates and zoom level."

Exposing pan/zoom events are valid feature requests that are logged in the Feedback Portal:

https://feedback.telerik.com/blazor/1565057-pan-event

https://feedback.telerik.com/blazor/1565056-zoom-event

You can vote for them as their demand is not very high as of today.

"5. Click events are passed through the Image Layer for processing."

This is dependent on the implementation - if the image layer is rendered "on top of" other layers, then it might "swallow" all the events. Otherwise, the map itself might provide a way to execute a click event on all its layers (not generally applicable as there are scenarios when you do not want every layer to handle a click, but rather the one that you interact with).

Looking forward to your reply, where you can provide more details on the scenario.

Regards,
Stamo Gochev
Progress Telerik