Native WebGPU renderer for leaflet

[MatiasHiltunen]

Hello,

I would like to hear your opinion of this idea/proposal.

I'm up for the challenge on implementing lightweight native WebGPU renderer for the leaflet.

I have few years of experience working with WebGL solutions and shaders and as the WebGPU is slowly maturing, I would like to begin development with it as personal learning experience to achieve deep understanding of the native WebGPU development process. Goal is to achieve best possible performance with little-to-no library usage and keep things minimal while supporting existing features.

I'm probably going to do this "learning experience" anyways with something but the best motivation for me would be to have the work eventually on actual use and let the results benefit others aswell.

As the WebGPU still has no support in many browsers, I could make a fallback option to WebGL.

I'm aware that there are many forks and plugins that may already do this but I would really like to get hands-on with this and dive to the deep end so to speak.

So, let me know what you think of this and of course any tips and guidance are welcome!

Br. Matias

Slava Ukraini!

[IvanSanchez]

I've spent an awful lot of time in https://gitlab.com/IvanSanchez/leaflet.gleo , so... I'm wary of what you're attempting.

The most basic problems to solve in a WebGL/WebGPU renderer are the floating point precision issues (how are you going to deal with millimeter-precision geographical coordinates in float32 numbers?) and memory allocation issues (in Leaflet you can add any number of things to a map and then delete any one arbitrary thing).

I recommend you read through https://webgpufundamentals.org/ and ponder about the issues I pointed out.

[MatiasHiltunen]

Well, I wouldn't call that trivial ;) Nice work!

[MatiasHiltunen]

Of course there is no point to invent wheel again and WebGPU has a long way to replace webgl. Nonetheless, I'm probably going to do this anyway as the WebGPU is something that I'm going to focus on in the future.

WebGL solution for reading/calculating pixel values from tiles works nicely but what I would like to get is the ability to use raycaster to get a value from single pixel on texture and that is where WebGPU would be usefull, that probably would not benefit leaflet as 2D map rarely needs that ability.

Appreciate the good work you have done with webgl here!

[Falke-Design]

I think WebGL / WebGPU is a important topic if we want to keep Leaflet as a solution in the web. Also I think it will be easier to implement after the refactoring of v2.

I'm probably going to do this anyway as the WebGPU is something that I'm going to focus on in the future.

Yes please. If we will not add it to Leaflet core, you can provide it as a plugin anyway.

@IvanSanchez are there reasons why we would not want to add GL to Leaflet?

[IvanSanchez]

@IvanSanchez are there reasons why we would not want to add GL to Leaflet?

Code complexity. The API differences between SVG/Canvas and GL are really big. With GL there's a need to either dynamically allocate GPU RAM (the Gleo approach) or go full vector tiles (the MapboxGL/MapLibre approach), and either mean lots of code.

I should give another shot at making Leaflet-Gleo more comprehensive: automagically convert L.Markers into gleo Sprites and L.Polylines into gleo Strokes and L.TileLayers into gleo MercatorTiles and so on. It should help with some use cases, but at the same time there would be lots of plugin incompatibilities.

I mean, I did try to bring GL to Leaflet... OMG, 8 years ago. And I hit the floating point precision problems, hard. The outcome of all that is Gleo.

[MatiasHiltunen]

@IvanSanchez WebGPU has currently abstract-numerics available, which are 64bit floats or 64bit signed integers! https://google.github.io/tour-of-wgsl/types/abstract-numerics/

Drawback might be that those are calculated on cpu at compile time.

On WebGPU github there is open issue to add support for 64bit floats

[MatiasHiltunen]

I have made some progress. I started with a WebGPU tile layer plugin, in which I now have ability to load tile images as textures to create a basemap. I used Gridlayer as a starting point to enable support for existing features as much as possible and of course to have already existing features available.

Few things to note:

To enable usage of cross-origin images as textures, I used WGSL 'loadExternalTexture' feature which has limited ability to access its data (have not really looked much into that yet).

Another thing is that 'loadExternalTexture' takes currently, to my knowledge, only VideoFrame or video as uniform value. That might sound odd but that actually gives more flexibility because with VideoFrame it is possible to use zero-copy approach and videoframe also has convenient "close"-method which cleans up that from memory.

[MatiasHiltunen]

I did had to override current way of the screenspace panning to have it entirely implemented in WebGPU side.

[MatiasHiltunen]

Currently zoom and panning are working with WebGPU tile layer, next I'm trying to get MSAA to work so that quality of raster tiles can be improved.

After that I'll publish first demo, probably in couple of weeks

[MatiasHiltunen]

Just some notes of the current status.

Initially I was going to have render calls for each tile but creating a texture atlas or implementing batch rendering would greatly reduce number of render calls and would be a much more efficient way to render basemap in this case. Goal is still to be able to use zero-copy approach. Any suggestions how this would be optimal to create are welcome!

Using fetch to get image data as buffer straight to VideoFrame should allow very efficient way to handle tile images if creating a VideoFrame from buffer does not make a copy of the data loaded from network. Fetch API allows probably few benefits over Image element as the Response object from fetch handles the data in separate thread (like with .json method). VideoFrame as extranal texture is zero-copy by design and should allow very efficient way to handle tile images.

Results so far are engourging and I'm going to continue working on this and goal is eventually to have all the basic features implemented with WebGPU.

[Falke-Design]

Sadly I have not the experience to help you with that but I would be very interested to read through your code.