|
|
| Line 331: |
Line 331: |
| * If you download a large binary message as a Blob, we don't stream the data to disk, but instead back the Blob using an in-memory buffer. This is transparent to the page, but causes us to use more memory. Tracking bug is {{bug|704447}}. | | * If you download a large binary message as a Blob, we don't stream the data to disk, but instead back the Blob using an in-memory buffer. This is transparent to the page, but causes us to use more memory. Tracking bug is {{bug|704447}}. |
| * WebSockets aren't supported in Workers {{bug|504553}} | | * WebSockets aren't supported in Workers {{bug|504553}} |
|
| |
| = Asset Management =
| |
|
| |
| [https://games.etherpad.mozilla.org/19 Feedback from Games Work Week]
| |
|
| |
| From a game developer: ''"A robust resource/asset loading/unloading/streaming system - The browser is capable of doing a whole lot on this end, particularly streaming and fetching from remote sources. However, a game developer's problem isn't just obtaining and loading the assets, it's managing them from a memory and "readyness" point of view. This is especially key in mobile spaces where you are severely constrained by memory and the traditional mindset of "load all of a level's assets at start and play" begins to break down."''
| |
|
| |
| Gladius is actually working on code for this, and our current theory is that we expect to split it out into a standalone library before too long.
| |
|
| |
| IndexedDB will write separate Blobs as separate files in the OS file system. Is OS file system too slow? Especially when scaling up to lots of files in a single OS directory.
| |
|
| |
| How big are these files usually. We've been talking about making the IndexedDB back-end collapse small files into a big OS-file. This would reduce reliance of OS large-directory handling.
| |
|
| |
| We're working on file writing. That might work as a back-stop for the most advanced use cases.
| |
|
| |
|
| = Multithreaded programming = | | = Multithreaded programming = |