Latest Contributions by mgeorge

Ah ok great! Yes, one of the advantages of using the hosted services here is the generalization. With this, the service reduces the number of vertices one the line to what you can actually see on the screen at a given scale. This can massively reduce the amount of data the client needs to hold onto at any given point in time, loading the more precise data only when the user zooms in. Also we don't have to store all the data in the service, only the data on screen (and since 4.17 we actually keep the data the service returns to us, which is a pbf-encoded binary payload, in its compressed format always and work on the compressed data directly).  Unfortunately with the feature collection, we also have to duplicate how we store the data (for threading). This is because shared memory is a bit of awkward thing in JS -- we use shared array buffers when possible (specifically for processed features we use this to store attribute data), but it's quite hard to share arbitrary json data between threads.  And like you mentioned there may also be some real memory issue that was fixed in 4.17, despite there now being some other graphical problem... ... View more

@ChrisShaw if you can you provide a repro on codepen I can take a look. You can also try against /next and see if things are fixed. There were some fixes for clipping on tile boundaries that are in the 4.18 branch:  https://github.com/Esri/feedback-js-api-next  ... View more

@AndrewMurdoch1 - is this the same as the other app where you are seeing the graphical bug in 4.17? Performance-wise, if you are able to use hosted feature layers (rather than query geojson -> create feature-layer from feature collection), that should perform dramatically better. With lines, server-side generalization can improve performance immensely. With the client-side feature collection, it requires loading all the data upfront and building spatial indices/querying/quantizing/re-projecting all on the client.  1 larger feature layer will also usually perform better than many small ones because each feature layer includes some upfront memory costs. ... View more

Ok great! (Just realized I posted with the wrong account 😅 - this is my official one) ... View more

Hi Stacy. Yes sorry, we did a hotfix for this.  ... View more

Yes ... it took us a while but we were finally able get this in! Let me know if you run into any issues. ... View more

Hi Tom,  For Vector Tiles, we do indeed use the Mapbox Vector Tile spec. The f=pbf format of FeatureServices however is an esri Feature Tile serialization spec. Feature Tiles are more for dynamic visualizations, whereas Vector Tiles are better for things like basemaps.  The documentation on this has been held up, but I think more details should be forthcoming. I'll check in again.  We've also worked to improve the performance of pbf encoded Feature Tiles in our upcoming 4.17 release. Whereas before we were doing some quite a bit of conversion to deserialize features, we've reworked things so that we can work directly against the compressed binary data.  Matt ... View more

4.17 is releasing very soon. This seems to be a race condition, so slight differences in timings (from misc. code changes, etc) could all contribute to whether or not this happens in particular versions.   ... View more

Sorry Andrew Murdoch‌! I would like to say yes, but this isn't the kind of thing we usually backport (that's mainly reserved for browser breaking changes that prevent earlier versions of the API from working) ... View more

Andrew Murdoch‌ I just installed a fix into our 4.17 dev branch, which seems to at least fix my repro. I'll let you know when that get's pushed to /next.  ... View more

Thanks! I think I can repro this with https://codepen.io/matt9222/pen/rNePaLW?editors=1000. Seems to be a timing issue with removing a layer while it's still loading.  This is on ubuntu 20/chrome (using an outdated chrome due to the latest version having super borked devtools on linux). Need to have devtools open + cache disabled (can repro maybe 30% of the time).  I think these should be "ok" errors as they are basically just aborts - we should be catching them though (& rethrow only if not an AbortError). Taking a look.  ... View more

Ah ok so you are getting the loop.  ... View more

You can send it to me (mgeorge@esri.com), however I think the HAR capture likely won't help us much here. We've made a bunch of changes to the way feature layers load, as well as fixed a rare issue that could happen with the workers communication, so it might be best to wait for that and see if we can still see the problem (the changes are currently live on /next).  ... View more

Oh sorry, if what I think is happening is actually what's causing the issue, it would only theoretically happen if the layer is added and removed very quickly. Just adding a feature layer shouldn't cause the problem.  ... View more