Reusing browser codecs to load images is a common tactic in web builds. It allows shrinking generated code by quite a bit by not having to ship image decoders in wasm, and browsers do parallelize image decoding since web pages are generally filled with images.
See here for a small example: https://github.com/juj/webgl_render_test , in particular this function that does the uploading: https://github.com/juj/webgl_render_test/blob/bb517e34dfaa13404feaa8a5ba8bf42c32581c44/src/library_js.js#L32 Online version available here: http://clb.confined.space/greetings/ With respect to performance, it is tough to say whether Wasm threading+custom image decoders would be more performant than JS Image based decoders - that is something I haven't benchmarked in detail. It probably depends on the nuances for the kinds of features that one needs for the decoding. (CPU access, processing, access to metadata info, etc.) su 14. helmik. 2021 klo 21.20 Shachar Langbeheim ([email protected]) kirjoitti: > > BTW, it's not only more efficient, but it also ensures that the browser will > handle things like EXIF rotation for you. > > On Sun, 14 Feb 2021 at 21:23, Shachar Langbeheim <[email protected]> wrote: >> >> Yes, that's exactly what we do in https://app.boosted.lightricks.com/ . We >> benchmarked the various ways to move the texture information from the JS FE >> to the C++ OpenGL implementation, and the fastest method was to create an >> HTMLImage/VideoElement and load the texture content using texImage2D, and >> then just to pass the texture handle to the WASM code. We did need to copy >> the way that Emscripten gives each texture a unique handle , in order to >> access the textures in C++. >> >> On Sun, 14 Feb 2021 at 20:42, 'Phil Endecott' via emscripten-discuss >> <[email protected]> wrote: >>> >>> Dear List, >>> >>> I've been using Emscripten to port an OpenGL project and I am >>> impressed by how well it works, so far. >>> >>> My original code decompresses JPEG images and loads them into >>> textures on background threads. For Emscripten I've disabled that, >>> and it does impact performance. >>> >>> I am wondering whether the best solution to this would be to >>> download, decode and load the images in Javascript. Specifically, >>> MDN has an example here: >>> >>> https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL >>> >>> Basically it creates an Image object, sets its src attribute >>> to the URL to download, and sets an onload handler that calls >>> gl.texImage2D to load it into a texture. >>> >>> Potentially, this might use more efficient JPEG decoding and >>> might do that decoding on a different thread. >>> >>> Has anyone tried anything like this? Does anyone know whether >>> browsers do, in practice, use secondary threads and/or faster >>> decoders than libjpeg-turbo, for decoding JPEGs? >>> >>> >>> Thanks, >>> >>> Phil. >>> >>> >>> >>> >>> -- >>> 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]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/emscripten-discuss/1613328173462%40dmwebmail.dmwebmail.chezphil.org. > > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/CA%2B_KjGbdD0tn-N2vxSZfsOs3%3DLMc_m%2BibPCnb82%2BN3rsnysukQ%40mail.gmail.com. -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2B6sJ-2%3DODyF4Wsq8%2BQL50p2oJwaH%3DcwCVc%3DzRGoSqzM3%2Bfibw%40mail.gmail.com.
