Important: Please read the Qt Code of Conduct -

Qt WebAssembly with OpenCV

  • I have tried Qt for WebAssembly with the provided examples and a simple custom widget with OpenGL ES 2.0/3.0 works fine (*Only QOpenGLContext::makecurrent in non-main thread will lead to crash even the context is created in the calling thread. Maybe a bug). I have a question on using external library, e.g. OpenCV here. I have compiled OpenCV with emscripten. Using QtCreator to add external library

    unix:!macx: LIBS += -L$$PWD/path/to/opencv/build_wasm/lib -lopencv_core
    INCLUDEPATH += $$PWD/path/to/opencv/install/include/opencv4
    DEPENDPATH += $$PWD/path/to/opencv/install/include/opencv4
    unix:!macx: PRE_TARGETDEPS += $$PWD/path/to/opencv/build_wasm/lib/libopencv_core.a

    The build is fine but when run with Firefox (emrun), the following error shown on the browser.

    Qt for WebAssembly: Test
    TypeError: Response.arrayBuffer: Body has already been consumed.

    When I removed all the OpenCV dependencies again, the program runs without problem on Firefox.

    --More Information---
    I have built from source the whole Qt 5.15.1 with emscripten that enables multithreading on Ubuntu20.

  • @ihmc This is marked as "solved" - so what's the solution?

  • I ran into the same problem with Firefox giving me: TypeError: Response.arrayBuffer: Body has already been consumed.

    The problem for me was not related to the .wasm but to the qtloader.js file that qt uses to load the .wasm file. It appears to have a bug where it tries to read the arrayBuffer (body) of a fetch request twice (which is not allowed and results in the above error). This code path is only hit when WebAssembly.compileStreaming throws an error. Because qtloader.js catches this error all you see is the TypeError: Response.arrayBuffer: Body has already been consumed.

    In my case the underlying error was caused by using brotli content compression on the .wasm file without a https connection. It looks like firefox throws an exception without any error message in this case which is caught inside qtloader.js and hidden so it's not obvious at all that this was the issue. I think any error thrown by WebAssembly.compileStreaming should cause the same problem though.

Log in to reply