Consider to disable Three.js Cache

[takahirox]

Is your feature request related to a problem? Please describe.

We Hubs (more precisely underlying A-Frame) enables Three.js Cache which saves the file contents downloaded with Three.js loaders in JavaScript level in heap memory.

But I think browser also saves the cache and it should work fine. So JavaScript level cache may be useless.

And JavaScript level cache unnecessarily wastes heap memory. File contents cache can be one of the huge memory consumption in Hubs Client.

I tried to measure the benefit of disabling the Three.js Cache with a very easy way.

1. On the local Hubs server, I joined a room with "Moz Atrium" scene.
2. Take heap memory snapshot on Windows10 Chrome
3. Run THREE.Cache.clear() on the web console (thanks for global THREE)
4. Take heap memory snapshot again

Result:
Before clearing Three.js Cache: 117.0MB
After clearing Three.js Cache: 75.3MB

I cut off 35% heap memory consumption by just clearing the Cache. The effect would be greater if a lot of medias, objects, and avatars are placed especially in a longer event where people tend to be place (and remove) a lot of objects over time.

Describe the solution you'd like

Disable Three.js Cache. It is disabled by default in Three.js so it can be done by removing THREE.Cache.enabled = true line from A-Frame code.

Describe alternatives you've considered

If we want to enable Three.js Cache for certain reasons, we should remove the file contents which unlikely be used again from Cache by THREE.Cache.remove(url).

Additional context

There may be some codes in A-Frame which expects and relies on that Three.js Cache is enabled. Just in case we should carefully check and review such codes. (But we may not need to be worried about it since we use very little of the built in stuff now.)

I'm thinking of starting to work on this after #4198 is merged.

[arpu]

for testing without aframe change: setting THREE.Cache.enabled = false, works too after importing aframe

[takahirox]

In our A-Frame fork, there seems to be only four places where A-Frame directly touches THREE.Cache.

1. Initialize THREE.Cache as THREE.Cache.enabled = true in lib/three.js.

2. THREE.Cache.remove(data.src) in components/sound.js.

3. Save image element as THREE.Cache.files[imgEls[i].getAttribute('src')] = imgEl in core/a-assets.js.

4. Save video element as THREE.Cache.files[el.getAttribute('src')] = el in core/a-assets.js.

Ideally we shouldn't edit A-Frame fork because managing our specific code is costly. So overriding THREE.Cache configuration on our Hubs end as THREE.Cache.enabled = false would be the first option we should think of.

But 3 and 4 are problematic. They directly saves data into THREE.Cache.files. THREE.Cache.enabled = false can't prevent that.

Object.freeze(THREE.Cache.files) may work. But storing data into a frozen object throws an error in JavaScript strict mode. Even if we currently don't use strict mode, there might be a chance that we enable the strict mode at some points. I would like to avoid such a future problem.

Overriding THREE.Cache.files with Proxy may be another option.

But probably the cleanest way is editing the code in our A-Frame fork.

[takahirox]

I suggested to our A-Frame fork and the upstreaming A-Frame that we should replace THREE.Cache.files[url] = file with THREE.Cache.add(url, file) which would be more proper API.

THREE.Cache.add() has no effect if THREE.Cache.enabled = false. So if the change is merged, we will be able to control THREE.Cache enabled/disabled on our end.

[netpro2k]

I personally think we shouldn't worry too much about modifying our aframe fork at this point. We have already stripped out a lot of it, and don't rely on almost any of the built in components anymore which is where most of the ongoing work goes into, so its unlikely we will really be pulling in many changes from upstream.

After we get threejs updated I would like to start pulling out some of the initialization code in aframe into hubs, so that we have more direct control over initializing the renderer and raf loop.

Sending a PRs upstream where it makes sense is always nice to do though.