Issues with webGL performance and support

4786
12
Jump to solution
03-04-2021 10:24 AM
dmarkbreiter
New Contributor II

 

Problem

I've been developing a web application for the first time using the JS API. When testing the performance of the website, I've had perfectly snappy use on relatively new hardware (such as my Surface Laptop 3 8GB RAM, Chrome v88) but cripplingly slow use on somewhat old hardware (MacBook Pro 13" 2016 8GB RAM, MacBook Pro 15" 2014 8GB RAM, Dell Inspiron 15 5000 2017 8GB RAM, all running Chrome v88). 

Link to web app in development:

 

Troubleshooting

Considering how these "older" hardware aren't very old, the laggy performance is troubling. At first I thought it might be a basemap or feature service that was slowing down the application, but when I tested sample apps on the developer page for the API, I had equally if not slower performance.

Example apps linked below:

The above apps work perfectly fine on my Surface Laptop 3, but absolutely limp along on the other tested hardware configs. 

UPDATE I

Looking at my own app, I see that two feature services (LAU_Localities_View and SoCal_Counties) have multiple GET requests at page load. I've included the Query String Parameters of one of them below:

The first thing that strikes me as weird is the low maxRecordCountFactor of 3.

 

 

 

f: pbf
geometry: {"spatialReference":{"latestWkid":3857,"wkid":102100},"xmin":-13149614.849954996,"ymin":3757032.814274987,"xmax":-12993071.816026995,"ymax":3913575.8482029866}
maxRecordCountFactor: 3
resultOffset: 0
resultRecordCount: 8000
where: 1=1
orderByFields: OBJECTID ASC
outFields: OBJECTID
outSR: 102100
quantizationParameters: {"extent":{"spatialReference":{"latestWkid":3857,"wkid":102100},"xmin":-13149614.849954996,"ymin":3757032.814274987,"xmax":-12993071.816026995,"ymax":3913575.8482029866},"mode":"view","originPosition":"upperLeft","tolerance":305.74811314062526}
resultType: tile
spatialRel: esriSpatialRelIntersects
geometryType: esriGeometryEnvelope
inSR: 102100

 

UPDATE II

It looks like the warning regarding graphics driver support for webGL is the culprit. Chromium based browsers seemed to suffer, but the issue seemed to only persist for about a day (no updates were performed on Edge 88 or macOS Catalina).

Question

Is this the expected behavior/performance of web applications built using the API?

If not, how can I make my application more performant on a variety of hardware configs? Even panning around a basemap feels and looks choppy on this hardware. 

 

12 Replies
DamonDamon
New Contributor

Is this what you're looking for? Yes, I have a very old OS, but it weirdly works when using the Google Chrome browser, but that's not my default or the one I like to use:

Untitled.png

It's also strange that I can use it when I open it in Arcgis and their classic viewer. This is looking more like it'd be an issue with the state website and the Firefox browser, huh?

0 Kudos
mgeorge
Esri Contributor

@DamonDamon 

Also would need to know the CPU model & discrete GPU model (if there is one). Safari, Chrome, and Firefox all have their own APIs that go from WebGL -> GPU driver instructions, so it's often the case that you'll see different behavior or different platforms due to either (1) bugs in the browser or (2) browser-specific workarounds for bugs in graphics drivers. 

MapViewer Classic does not always use WebGL, and when it does, it's a very early version of the 4x engine. So I would also expect to see differences there when it comes to WebGL-related browser/driver-specific issues. 

0 Kudos
RenatoTeixeira1
New Contributor III

I solve this problem on my MacOS Monterey.

Open your safari, go to preferences > advanced tab, enable show Developer menu, after that access Experimental features menu into Developer Menu on top menu bar, and than disable all webgl option that are enable. Reload you page.

0 Kudos