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 older 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:
https://dmarkbreiter.github.io/lau-interactive/
Troubleshooting
Considering how these "older" hardware configs 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:
https://developers.arcgis.com/javascript/latest/sample-code/featurelayer-query/
https://esri.github.io/dot-density-legend/
https://livingatlas.arcgis.com/sea-ice/
The above apps work perfectly fine on my Surface Laptop 3, but absolutely limp along on the other tested hardware configs.
UPDATE
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:
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
The first thing that strikes me as weird is the low maxRecordCountFactor of 3.
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. Is this a known issue and if so, is there any workaround to ensure useable performance on a variety of hardware?
It would appear that the issue is with Esri's WebGl engine and it not working with the machine's graphics driver as evidenced by the following console warning on Chrome based browsers:
[esri.views.2d.engine.webgl.WebGLDriverTest] A problem was detected with your graphics driver. Your driver does not appear to honor sampler precision specifiers, which may result in rendering issues due to numerical instability. We recommend ensuring that your drivers have been updated to the latest version. Applying lowp sampler workaround. [0.0.0.0]
When the web apps linked in the question were tested on FireFox 86, they worked perfectly fine and without the warning above.
Related
I am using the objective-c framework for WebRTC for building a screensharing app. The video is captured using CGDisplayStream. I have a working demo but at 2580x1080 I get only 3-4 fps. My googAvgEncodeMs is around 100-300ms (should be >10ms ideally) which explains why the screensharing is far from being fluid (30fsp+). I also switched between codecs (h264/vp8/vp9) but with all of them I get the same slow experience. The contentType in webRTC is set to screen (values: [screen,realtime]).
The cpu usage of my mac is then between 80-100%. My guess is that there is some major optimisation (qpMax, hardware-acceleration etc...) in the c++ code of the codecs that I have missed. Unfortunately my knowledge on codecs is limited.
Also interesting: Even when I lower the resolution to 320x240 the googAvgEncodeMs is still in the range of 30-60ms.
I am running this on a MacBook Pro 15 inch from 2018. When running a random webrtc inside Chrome/Firefox etc I get smoother results than with the vanilla webrtc framework.
WebRTC uses software encoding and that is the real culprit. Also encoding 2580 x 1080 in software is not going to be practical. Try reducing H and V resolution in half and it will improve performance with some loss in quality. Also if you are doing screen sharing and video support is not critical, you can drop frame rate to 10 frames per second. Logical solution is to figure out how to incorporate h/w acceleration.
We are using chrome lighthouse extension for running tests on our pages and improves performances score. We have however a problem. On a MacBook Pro-2015, we get a 94 performance score and also 94 performance score in a Windows virtual machine running on the laptop. However on a 64-bit Windows laptop with an Intel Pentium n3540 CPU, we get below 50. Even demo pages found online that claim 90+ score will not go above 50 on this system.
Are there any specific requirements that the lighthouse has in order to run correctly? Or some special settings need to be done on the Windows system?
Lighthouse can be configured to run on most systems, nothing precludes it from running on windows (it should run on windows out of the box), but there will definitely be variation based on the system that it runs on un-throttled. If you want a consistent bar to run against consider running against WebPageTest. Or play with their custom settings to get an audit that is exactly what you want that can be run consistently.
I think that running lighthouse on a computer with a chip that was released 4 years ago will probably yield low results, as you are experiencing. Which is probably an accurate depiction of how performant a website will be on that hardware. This might be a case of WAI.
Are you running Lighthouse with simulated throttling, or with throttling off? That can also increase variation.
This webcam (Microsoft LifeCam VX-700) can record from Rasberry Pi 3 Model B. The FPS is somewhere from 3-5 FPS on this sample https://codeload.github.com/ms-iot/samples/legacy.zip/master (WebCamSample). Anyway to improve the FPS?
The reason for this slow framerate is that there currently isn't an optimized GPU driver that enables hardware acceleration to its full potential.
When you look at the Device Portal (admin site of the device on port 8080) you will notice in the performance tab that it mentions GPU but can't show any statistics. As soon as we get a build that includes the new driver I expect us to see some metrics there and vastly improved video performance.
This is a know issue, a big one as well, but as far as I understood people are working on it.
Lowering the resolution will help, obviously.
I tried using "Kinect for Windows" on my Mac. Environment set-up seems to have gone well, but something seems being wrong. When I start some samples such as
OpenNI-Bin-Dev-MacOSX-v1.5.4.0/Samples/Bin/x64-Release/Sample-NiSimpleViewer
or others, the sample application start and seems working quite well at the beginning but after a few seconds (10 to 20 seconds), the move seen in screen of the application halts and never work again. It seems that the application get to be unable to fetch data from Kinect from certain point where some seconds passed.
I don't know whether the libraries or their dependency, or Kinect's hardware itself is going wrong (as for hardware, invisibly broken or something), and I really want to know how to detect which is it.
Could anybody tell me how can I fix the issue please?
My environment is shown below:
Mac OS X v10.7.4 (MacBook Air, core i5 1.6Ghz, 4GB of memory)
Xcode 4.4.1
Kinect for Windows
OpenNI-Bin-Dev-MacOSX-v1.5.4.0
Sensor-Bin-MacOSX-v5.1.2.1
I followed instruction here about libusb: http://openkinect.org/wiki/Getting_Started#Homebrew
and when I try using libfreenect(I know it's separate from OpenNI+SensorKinect), its sample applications say "Number of devices found: 0", which makes no sense to me since I certainly connected my Kinect to MBA...)
Unless you're booting to Windows forget about Kinect for Windows.
Regarding libfreenect and OpenNI in most cases you'll use one or the other, so think of what functionalities you need.
If it's basic RGB+Depth image (and possibly motor and accelerometer ) access libfreenect is your choice.
If you need RGB+Depth image and skeleton tracking and (hand) gestures (but no motor, accelerometer access) use OpenNI. Note that if you use the unstable(dev) versions, you should use Avin's SensorKinect Driver.
Easiest thing to do a nice clean install of OpenNI.
Also, if it helps, you can a creative coding framework like Processing or OpenFrameworks.
For Processing I recommend SimpleOpenNI
For OpenFrameworks you can use ofxKinect which ties to libfreenect or ofxOpenNI. Download the OpenFrameworks packaged on the FutureTheatre Kinect Workshop wiki as it includes both addons and some really nice examples.
When you are connecting the Kinect device to the machine, have you provided external power to it? The device will appear connected to a computer by USB only power but will not be able to tranfer data as it needs the external power supply.
Also what Kinect sensor are you using? If it is a new Kinect device (designed for Windows) they may have a different device signature which may cause the OpenNI drivers to play-up. I'm not a 100% on this one, but I've only ever tried OpenNI with an XBox 360 sensor.
Currently I am using the DTWGestureRecognizer open source tool for Kinect SDK v1.5. I have recorded a few gestures and use them to navigate through Windows 7. I also have implemented voice control for simple things such as opening PowerPoint, Chrome, etc.
My main issue is that the application uses quite a bit of my CPU power which causes it to become slow. During gestures and voice commands, the CPU usage sometimes spikes to 80-90%, which causes the application to be unresponsive for a few seconds. I am running it on a 64 bit Windows 7 machine with an i5 processor and 8 GB of RAM. I was wondering if anyone with any experience using this tool or Kinect in general has made it more efficient and less performance hogging.
Right now I removed sections which display the RGB video and the Depth video but even doing that did not make a big impact. Any help is appreciated, thanks!
Some of the factors I can think of are
Reduce the resolution.
Reduce the frames being recorded/processed by the application using polling model i.e. OpenNextFrame(int millisecondsWait) method of DepthStream, ColorStream & SkeletonStream
instead of event model.
Tracking mode is Default instead of Seated(sensor.SkeletonStream.TrackingMode =
SkeletonTrackingMode.Default) as seated consumes more resources.
Use sensor.MapDepthFrameToColorFrame instead of calling sensor.MapDepthToColorImagePoint method in a loop.
Last and most imp. is the algorithm used in the open source tool.