Very high latency in MVT layer when loading tiles.

[smcallis]

I benchmarked my deck.gl in Chrome and I noticed some latency oddness I'm hoping someone can help me with. I'm using an MVTLayer and the tiles in this particular case aren't that big, about 800KB, but when I load the page it can take up to 20s for the tiles to become visible, long after they've actually finished downloading:

It looks like deck.gl doesn't do anything until a random AnimationFrameFired occurs, then it initializes the layers:

Is there any way to force this to happen as sooner as the tile data is ready?

[smcallis]

Perhaps the issue is in my custom fetch function if that helps:

         fetch: async (url, { layer, loaders, loadOptions, signal }) => {
           // MVTLayer stores a special loader on its properties.
           loaders = loaders || layer.props.loaders

           const retrieve = async function(options={}) {
             return fetch(url, {
               credentials: "include",
               ...options
             });
           }

           const parseData = async function(data) {
             return window.loaders.parse(data, loaders, loadOptions);
           }

           // Try to retrieve the data.  If we get an error, retry without CORS
           // enabled to load any authentication cookies that are needed, and
           // retry.
           return new Promise((resolve, reject) => {
             retrieve()
               .then(data => resolve(parseData(data)))
               .catch(error => {
                 console.log(`Fetch failed ${error}, retrying`);
                 retrieve({mode: 'no-cors'})
                   .then(data => {
                     retrieve()
                       .then(data => resolve(parseData(data)))
                       .catch(reject); })
                   .catch(reject);
                 });
           });
         },

[smcallis]

Actually I think it's the data parser:

[ibgreen]

I believe the MVTLayer supports a binary mode flag, which would avoid the conversion to and from GeoJSON.

[smcallis]

My understanding is that binary: true is the default, but I just tried adding it and it didn't make a difference.

[ibgreen]

Looking at your call stack it looks like the MVTLoader is converting binary to GeoJSON. You could check if that is still happening after setting the prop. If so we could eliminate that as the issue.

[smcallis]

Done, this is the current stack:

I can't even find the classifyRings2 function...

[smcallis]

Nevermind it's just that there's a separate classifyRings function so it got renamed when bundling. It's a BinaryVectorTileFeature so I think it's reading it as binary, but the ring classification is just a killer for polygons. When I load a tile full of points it's not a problem.

[smcallis]

For perspective, the tile is 11608 polygons with a total of 1,855,149 points, about 160 points/polygon. So not small but not 15 seconds worth of processing either.

[smcallis]

I rewrote the getPolygonSignedArea() function without the loop cleverness to help the JIT and it's night and day faster, this is the code:

 function getPolygonSignedArea(points, options = {}) {
    const {
      end = points.length,
      plane = "xy"
    } = options;

    const dim = options.size || 2;
    const i0 = DimIndex[plane[0]];
    const i1 = DimIndex[plane[1]];

    let Area = function(curr, prev) {
      return
        (points[curr + i0] - points[prev + i0])*
        (points[curr + i1] - points[prev + i1]);
    };

    let area2 = Area(0, end-dim);
    for (let i = dim; i < end; i += dim) {
      area2 += Area(i, i - dim);
    }
    return area2/2;

And this is the stack trace now, classifyRings is in the millisecond range now and fillArrays is the bottleneck:

[ibgreen]

@smcallis This looks very promising indeed. I made a change to math.gl to use your math however I can't replicate the results in our benchmarks, if you look at the Bench section in:
https://github.com/visgl/math.gl/actions/runs/10433413865/job/28895112777?pr=19
admittedly those bench tests run under Node 20, not in the browser/puppeteer so it may not be apples to apples.

[smcallis]

I'm definitely far from an expert in appeasing the JIT, all I can really say is it got faster for me, mileage may vary for others. It looked like the getPolygonSignedArea() code in HEAD in math.gl was a little different than the one that was bundled with the latest deck.gl, so that might affect things too, maybe it's been fixed already?