> it is tough to say whether Wasm threading+custom image decoders would be more performant than JS Image based decoders
AFAIK This is going to vary significantly between the files and hardware - it very much depends on whether your setup has HW codecs for the specific video format you us. This might be a lesser consideration for images, but when decoding video and trying to reach 60 FPS it's a pretty big deal. On Mon, 15 Feb 2021 at 00:16, Jukka Jylänki <juj...@gmail.com> wrote: > 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 (niho...@gmail.com) > 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 <niho...@gmail.com> > 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 < > emscripten-discuss@googlegroups.com> 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 emscripten-discuss+unsubscr...@googlegroups.com. > >>> 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 emscripten-discuss+unsubscr...@googlegroups.com. > > 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 emscripten-discuss+unsubscr...@googlegroups.com. > 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 > . > -- 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 emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CA%2B_KjGb_Raaqq6Uo0i-99Cxw-pUMszrPWGojMzh8dHHNo3FZyw%40mail.gmail.com.
