tl;dr: if you preload images and audio, and rely on emscripten's support
for decoding those automatically during startup - as opposed to you
decoding them in software, using libpng, std_image, or some other compiled
library - then you will now need to build with --use-preload-plugins

We made a change on incoming recently, details are in

https://github.com/kripken/emscripten/issues/3785

Background: emscripten has by default pre-decoded images and audio, using
it's preload plugin system. Each preloaded file would be processed there
based on the file suffix. For images, for example, we'd create an Image
element and let the browser decode it. The image would then be ready for
use in SDL, as the decoded image was already in memory.

This is convenient, but it does take memory to store all those decoded
images, and it's hard to know when to free it (an image might be loaded
twice, or never loaded at all). As mentioned in that issue, this can be a
surprising catch on projects with large amounts of preloaded files.

On incoming, we no longer do that by default. But, you can enable the old
behavior with --use-preload-plugins (either in emcc or the file packager,
if you package files separately).

BananaBread for example relies on browser decoding of images and audio (to
minimize download size, we don't build in any compiled codecs), so it was
updated here:

https://github.com/kripken/BananaBread/commit/347a8dd7a63d6778f6960767c3e9d5544c2dd009

- Alon

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to