Hi all,

We are leveraging Qt's fine Wasm/Emscripten platform support in a project where we compile LibreOffice with Emscripten to run in the browser (see <https://zetaoffice.net/>). We are currently based on a slightly patched, old Qt 5.15.2 version (see <https://github.com/allotropia/qtbase/tree/5.15.2%2Bwasm>).

We need Emscripten's -sPROXY_TO_PTHREAD setting (see <https://emscripten.org/docs/tools_reference/settings_reference.html#proxy-to-pthread>, which moves the application's main thread off the browser main thread into a pthread, to which it transfers any canvas DOM element as an OffscreenCanvas upfront). We need that, among others, because the LibreOffice code wants to arbitrarily spawn further threads from within event loop callbacks, something that would run into deadlocks without -sPROXY_TO_PTHREAD.

Qt does not appear to support -sPROXY_TO_PTHREAD out of the box. But for that old Qt 5.15.2, it was relatively easy to patch things up: There was only a single qtcanvas DOM element, so Emscripten can be instructed to transfer it with -sOFFSCREENCAVNASES_TO_PTHRAD=#qtcanvas. And Qt code that accessed browser functionality that is only available on the browser's main thread (so cannot be accessed directly any more with -sPROXY_TO_PTHREAD) was relatively rare, and I patched that up by sprinkling in some emscripten_async_run_in_main_runtime_thread etc., and that appeared to mostly work well enough.

Now, with recent Qt 6, things have apparently changed rather drastically. There is no longer a single #qtcanvas DOM element, but each window is its own, dynamically added canvas element, and interaction with browser functionality that is only available on the browser's main thread has grown significantly. To a point that I quickly gave up trying to carry my patching approach forward :)

So, my question is what the general opinion here is regarding support for Emscripten's -sPROXY_TO_PTHREAD in today's Qt 6. Has this been discussed before? Is it considered something that you wouldn't want to support, or something that would be supported if somebody set out to actually implement it, or...?

Thoughts welcome,
Stephan
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to