We Keep Coding

p5.js sketch very slow on mobile devices

I'm building a creative simulation in p5.js by employing double pendula. Here is the link to the stripped-down version of the code (I'm not sure it can be made smaller):
https://github.com/amzon-ex/amzon-ex.github.io/tree/master/dp-sketch-stripped
Here is where you can see the animation: https://amzon-ex.github.io/dp-sketch-stripped/dp-sketch.html
When I run this on my laptop (Windows 10, MS Edge 88) I get about 55-60 fps, which is what I want. However, when I run the same sketch on a mobile device (Android, Chrome 88) the performance is very poor and I hardly get 5-6 fps. I do not understand what is complicated about my code that contributes to such a poor performance. I have ran other kinds of p5.js sketches before on mobile and they've worked well.
Any insight is appreciated.
Since I have a few files in the project link I provided, here's a quick guide (there is absolutely no need to read everything):
sketch.js is the key file, which builds the animation. It takes an image, builds an array filled with brightness values from the image (array lumamap, in setup()). Then I draw trails for my pendula where the brightness of the trail at any pixel corresponds to the brightness value in lumamap.
dp-sketch.html is the HTML container for the p5 sketch.
libs/classydp.js houses the DoublePendulum class which describes a double pendulum object.

As I've found out with some help, the issue is tied to varying pixel density on different devices. As mobile devices have higher pixel density compared to desktops/laptops, my 500x500 canvas becomes much bigger on those displays, hence leading to many more pixels to render. Coupled with the fact that mobile processors are weaker in comparison to desktop processors, the lag/low framerate is expected.
This can be avoided by setting pixelDensity(1) in setup(); which avoids rendering larger canvases on dense-pixel devices.

WebGL supported but equirectangular panorama example from Three.js not working on device?

Looking at the WebGL equirectangular panorama example it works great on desktop and mobile (Samsung S4 Android 4.4.2) with latest version mobile Chrome.
However on the Samsung tablet SM-T230 also with Android 4.4.2 and latest version mobile Chrome the equirectangular panorama example does not work. Here also the device orientation control example does not work.
The only thing that mildly works on this device is the Canvas geometry panorama example and to my surprise the CSS3D panorama example works BEST!
So all this leaves me confused. The tablet does support WebGL but not certain parts of it work, like the Canvas geometry panorama example, even if not fluid and barely, but it supports it.
How can I find out if a device supports WebGL equirectangular panorama example or not? I am looking for a way to create a fallback for devices like the Samsung tablet SM-T230 where I would love to use the CSS3D version of the equirectangular panorama.
Now I have found many questions and answers on checking for WebGL support, Three.js even has a Detector.js that helps with this, but how can I find out if a particular device is going to love the equirectangular panorama part of WebGL?
Do I perhaps with Modernizr need to check for other certain sensors that a device needs to have to support the device orientation control example?
My aim is to have an equirectangular panorama with device orientation controls on PDAs that support it, on PDAs that don't use the CSS3D version panorama and on desktops the normal WebGL equirectangular panorama with mouse drag to see various parts of the spherical projection.
I think simply checking if WebGL is supported with Detector.js is not enough here. What else from the code but also from the hardware side would I need to take into consideration please?

An Introduction to the Device Orientation API
DeviceOrientation Event Specification
WebGL - 3D Canvas graphics
This solved my question. It was indeed the case that the T230 did not support the DeviceOrientationEvent including its 4 properties alpha, beta, gamma and absolute. In the test these are null and false. So I can use that to check for support and use CSS3D as a fallback where DeviceOrientationEvent is not supported.

HTML5 Device Orientation - reliable compass implementation?

I am working on a mobile web project that needs to know the compass direction the user's device is pointing. It's incredibly simple right now, but here's what I have:
var updateDirection = function (evt) {
$("#direction").val(evt.alpha);
};
window.addEventListener("deviceorientation", updateDirection);
Based on what I've researched so far, the alpha channel of the event should be the compass position. However, I've observed (and read) that there are a wide variety of implementations based on OS and browser.
On my HTC smartphone, in Chrome or the default Android browser, I only get a reasonable reading (0 degrees = North, 90 = East, so on) when I hold the phone perfectly vertical in a "selfie" position. Any angle to the phone throws readings quite far off.
On my Surface Pro using Chrome, I can't get a reading greater than about 50.
On my Surface Pro using Edge, I get very reasonable readings, but only when I hold the device horizontal, as if it was laying on a table.
It seems likely that people have achieved getting the compass direction in a mobile browser regardless of device. Is there some library I can use to do this? Or is it necessary to simply code for many different specific scenarios, like this example, which also didn't work for all the devices listed:
Device Orientation Events

Is that really necessary for you to use javascript to find out orientation?
You could possibly achieve the same result with CSS media queries

Why is 3D so slow on iPad3 Through Cocoon JS?

On a Nexus 7, the Gangnam Style Doom demo through CocoonJS runs at a healthy 35 FPS. On an iPad 3, the same demo runs at 5 FPS!
My own project (using ThreeJS) runs at 50-60 FPS on a Nexus 7 and on a cheap $100 Android handset (Cubot P9), runs at 30FPS. On an iPad3, it runs at around 15 FPS.
Why so slow on the iPad? The iPad3 runs most 3D games just fine, nice and smooth.
My own tests seem to indicate this is related to the number of 3D objects,not the number of polygons e.g. 100 low-poly cubes (1200 polys) is slow, whereas one object with 6000 polygons runs fast.
I don't think this is a ThreeJS issue, as the Gangnam Doom demo uses PlayCanvas.
I'm surprised no one else has noticed this. Has anyone tested the Gangnam demo on iPad 4/Air?
Any thoughts appreciated.

As far as I know the iPhone/iPad does not have 3d acceleration yet. That is why you get low FPS. On three.js you can choose which renderer to use. Either the WebGLRenderer (when there is acceleration) or the CanvasRenderer (when there is no acceleration). Android on the other hand, does support 3D acceleration so the speed you are seeing has only to do with how fast/slow the device is.

How does htmlcompass work?

I have a Wifi iPad and this compass actually knows the direction of north. Now I know it's quite possible to use the gyroscope data to fairly accurately track device rotations once north has already been established, but how on earth does it know the actual direction?
Now I'm pretty sure the ipad does not have a magnetometer... or does it? It's got a bunch of magnets all along its sides!
My reasoning is that if it didn't come with the Compass app, the device doesn't have a magnetometer.
Update: Okay I'm able to affect the result by moving a magnet around a stationary iPad. So it does have the magnetometer after all.

iPad and iPhone (3GS and later) have a digital compass (magnetometer) chip onboard, such as the AK8975 3-axis Magnetic field sensor.
By the way, it can be calibrated, see here: http://support.apple.com/kb/TS2767
In addition iPad also has gyroscope and accelerometer chips.
If you want to peek inside the iPad, check out the ifixit site and the teardown at chipworx.

Turns out iPad Wifi has a magnetometer.