[Development] Qt for WebAssembly status update

[Morten Sørvig via Development]

Hello all,

It’s been a while since the previous update so I figured it was time for a 
small “state of the union” on the WebAssembly port.

I’ll focus on topics which are most relevant to development of Qt itslef - all 
of the problematic parts that we should spend time on. Rest assured many things 
work already and it possible to build Qt applications for the platform :) Feel 
free to ask questions if there’s anything that should be discussed in more 
detail.

On to the list:


* Static and dynamic linking.


Static linking is the default, we are currently investigating dynamic linking.


It is expected that static linking will be default configuration for some time 
to come, where dynamic linking can be beneficial in special cases such as 
delayed loading of Qt libraries or sharing libraries between multiple 
applications (developing with shared libraries is also quite convenient since 
you can do incremental rebuilds)


Using dynamic linking currently requires patching Emscripten, and it does not 
work well with the asyncify feature (and earlier also not with threads, but 
that is looking better now)

* Thread support

Thread support is now stable (has been from some time), also with 
installer/binary packages. Emscripten implements pthreads on top of Web 
Workers. See https://emscripten.org/docs/porting/pthreads.html

Some issues remain:

- Threads require SharedArrayBuffer, which require putting the web page into 
cross-origin isolated mode, which places restrictions on cross-origin resource 
fetching.

- Blocking the main thread may deadlock, if the main thread is waiting for a 
pthread whose web worker has not been crated yet. This may require porting 
code, or pre-allocating threads with the PTHREAD_POOL_SIZE linker flag.

For these reasons we plan on keeping the no-thread mode supported going forwrad.

* exec() and asyncify

The web platform does not support blocking the main thread (not at all - 
pthread mutex is implemented using a spin-lock), and also does not provide a 
select()-style API which can wait for events. This makes implementing exec() 
and QEventLoop::WaitForMoreEvents difficult.

For QApplication::exec() we have a hack - exec() never returns and leaks the 
contents of the stack at the point when it’s called. This makes sure the root 
applications objects stay alive for the lifetime of the application. We also 
support a workaround: allocate on the heap in main(), don’t call exec(), and 
return early (see Emscripten EXIT_RUNTIME).

Long term, WebAssembly stack switching 
(https://github.com/WebAssembly/stack-switching) should make implementing 
exec() possible. In the shorter term we are utilizing Emscripten’s asyncify 
feature for this.

Asyncify comes in two versions:

- Asyncify 1: Supported on all browsers, but does not quite scale to Qt-sized 
software (increased build time, code size, CPU usage)

- JSPI (aka Asyncify 2): Supported on Chrome, behind a flag. No scaling issues.

So the current support situation here is not quite satisfactory. In addition we 
have also recently identified that we need to rework/improve the asyncify 
support in Qt. At the moment, porting away from using exec() might be the best 
option (Qt Quick apps generally don’t call exec() and should be fine here).


* Exceptions


Exceptions are disabled by default. Qt supports enabling native wasm exceptions 
using the  -feature-wasm-exceptions configure flag. Enabling exceptions breaks 
the QApplication::exec() hack, so we don’t enable it by default. (it’s also an 
optional part of the wasm spec, but supported by all mayor browsers).


Qt does not use exceptions so the non-support is OK in that regard, however we 
are using 3rdparty libraries which depend on exceptions (spirv-cross, assimp), 
which are causing issues.


* SIMD


Off by default, can be enabled at configure time with -wasm-simd-128. That 
allows the compiler to use SIMD instructions for loop auto-vectorization etc, 
but there are currently no wasm simd code paths in Qt. (Should we add more 
portable SIMD code paths to Qt? Using e.g. portable simd 
intrinsics/Highway/std::experimental::simd).


* Graphics


We are targeting WebGL 2 / OpenGL ES 3, and also support WebGL 1 / OpenGL ES 2 
for simple Qt Quick  “2D UI” use cases. All major browsers support WebGL 2; 
devices which don’t are maybe not a good target for Qt for WebAssembly.


WebGPU is interesting as a next step. The current high-level known issues are:


   - shader translation: spirv-cross does not support WGSL. The way forward is 
most likely to use a library like Tint here, but we don’t know if that covers 
all use cases required by Qt.

   - async: WebGPU is async in a couple of places where Qt is sync (from memory 
it is the GPU.requestAdapter() / GPUAdapter: requestDevice() initialization 
functions).


* Auto tests


We are continuing to port and enable auto tests. In some ways porting the tests 
is harder than porting Qt itself, since they have lots of sync code (block and 

Re: [Development] Trouble getting reviews in months and years

[Morten Sørvig via Development]

On Apr 12, 2024, at 11:51, Ilya Fedin  wrote:

On Thu, 11 Apr 2024 10:53:07 +
Morten Sørvig  wrote:

- Should Qt read Gdk settings? Should the XCB platform plugin read
Gdk settings? The current approach is that we stick to X11-level
settings, at least as far as DPI is concerned.

I hope the answer is yes. If it would be no, it would just block this
functionality without any good reason as there's no other API for this
on X11 (at least I'm not aware of).

It is the X11 platform plugin after all - which operates on the X11 level.  
Compare
with something like the gtkplatform plugin [1], which would definitively 
respond to
all GDK settings.

Going to reading private/undocumented GDK settings does look like a significant
change to me. I’m Ok with it if there is a consensus for going in that 
direction (the
patch is at +0 from my side right now).

I see the point about being pragmatic and behaving according to user preferences
though. Which Qt arguably already does to some degree since the text preference
is reflected in the Xft.dpi value.

Should this be up to the application (somehow)? There is more than one way to 
handle
DPI settings on X11, so we could enable apps to make choices which are different
from the Qt default.

- Morten


[1] https://github.com/CrimsonAS/gtkplatform


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Trouble getting reviews in months and years

[Morten Sørvig via Development]

Hello Ilya!

> On Apr 9, 2024, at 00:17, Ilya Fedin  wrote:
> 
> 
> 2. https://codereview.qt-project.org/c/qt/qtbase/+/444859 which is 1.5
> years old and no review
> 

This one could be candidate for discussion on the mailing list. There are two 
issues:

- Should Qt read Gdk settings? Should the XCB platform plugin read Gdk settings?
The current approach is that we stick to X11-level settings, at least as far as 
DPI is concerned.

- Should Qt support DPI-based text scaling? With Qt 6 we moved to uniform
scaling where the scale factor is applied to all UI elements. I think several
operating systems provide a “larger text” setting in some form, so this is 
something
we could look into if there is interest. But we have to make sure this does not
result in broken UI (clipped text etc), so I don’t think we should jump directly
to enabling it by default.

All in all I don’t think I’ll +2 this change as it stands.

> 
> 6. https://codereview.qt-project.org/c/qt/qtbase/+/519479 
> 
> 8. https://codereview.qt-project.org/c/qt/qtbase/+/528953 


These are of the “need to get around to it” category for my part. Adding new 
public
API can take a lot of time/effort. For 528953 we need to make sure we are not 
regressing
other platforms, and I have at least one related bug I’d like to take a look at 
at the
same time.

While we are on the topic - should we adopt a more structured approach to env 
variables
like QT_WIDGETS_HIGHDPI_DOWNSCALE? 

qputenv("QT_WIDGETS_HIGHDPI_DOWNSCALE", "1”) is the go-to approach for enabling
from application code, but as pointed out in 519479 that has the problem that 
the setting
is propagated to child processes, for example via QDesktopServices::openUrl(). 

This could be fixed by always having a corresponding “_q_foo” application 
attribute (or similar),
which would put environment variable users and source code users on equal 
footing.

- Morten


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Piotr Wierciński for approval status

[Morten Sørvig via Development]

I would like to nominate Piotr Wierciński for approver rights in the Qt project.

Piotr joined the Qt company early 2013 and has since then contributed to Qt for 
WebAssembly. This includes many bugfixes and also larger efforts such as 
getting tests running in the CI system.

Piotr is a pleasure to work with and I trust that he will make a good approver 
for the Qt project.

Changes:  https://codereview.qt-project.org/q/owner:piotr.wiercinski
Reviews:  https://codereview.qt-project.org/q/commentby:piotr.wiercinski 


Best regards,
Morten
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid

[Morten Sørvig via Development]

On 27 Jan 2023, at 18:04, Ilya Fedin  wrote:



My patch doesn't modify setScreenFactor, so the rounding is applied
only to the variable value (and to the property on QScreen object, as
it's the only remaining source without rounding in
QHighDpiScaling::screenSubfactor), so the programmatic calls of
QHighDpiScaling::setScreenFactor are unaffected.

However, it still rounds the value when reading it, and so 
tst_QQmlPreview::zoom() gets
a rounded value and fails. At least that’s what I’m seeing.

Here’s a new attempt: round the value when applying from the env. variable,
outside of setScreenFactor() which now keeps its existing behavior:

https://codereview.qt-project.org/c/qt/qtbase/+/460566

Morten


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The QT_SCREEN_SCALE_FACTORS rounding problem is still annoyingly valid

[Morten Sørvig via Development]

> On 25 Jan 2023, at 14:39, Ilya Fedin  wrote:
> 
> 
> This is a follow-up to the thread I started a year ago. The fix was
> momentally reverted back then leading to me patching Qt all that time. I
> still get reports from users using distribution packages as I obviously
> can't patch their Qt. The application is just unusable for those users
> using KDE's fractional scaling. I believe another attempt to fix this
> should be made, I've re-reported the bug as
> https://bugreports.qt.io/browse/QTBUG-110626.

Thanks for following up!

> I copied the patch I
> proposed in the previous report, why not to take this approach? Unlike
> https://codereview.qt-project.org/c/qt/qtbase/+/412296, it doesn't
> change the setScreenFactor method and shouldn't lead to the problems it
> was reverted due to.

That’s an interesting point, but how does it avoid the problems?

The failing test was tst_QQmlPreview::zoom() (if I remember correctly), which 
sets a screen scale factor and then verifies by reading 
screen.devicePixelRatio. So if any rounding is applied for scale factors like 
1.5 may cause the test to fail.

(The test has other problems, for example macOS applies native scaling which 
will cause screen.devicePixelRatio to differ from the Qt scale factor, so maybe 
it should be rewritten as well)

Morten


-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Fixing the 6.5 build when cross-compiling (missing Qt6::qtprotobufgen)

[Morten Sørvig via Development]

Hi, I’m running into a configure error for a top-level Qt 6.5 wasm build. I use 
“init-repository --module-subset=all” to check out the Qt modules.

The host system does not have protobuf installed, which configure warns me 
about during the host tools build (this is fine):

-- Configuring submodule 'qtgrpc'
-- [QtGrpc] CMAKE_BUILD_TYPE was set to: 'Release'
-- [QtGrpc] CMAKE_STRIP (original): 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)

But then, during the target (wasm) build the warning gets upgraded to an error:

-- Configuring submodule 'qtgrpc'
-- [QtGrpc] CMAKE_BUILD_TYPE was set to: 'Debug'
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Could NOT find Protobuf (missing: Protobuf_LIBRARIES 
Protobuf_INCLUDE_DIR)
-- [QtGrpc] Running syncqt.cpp for module: QtProtobuf
-- [QtGrpc] Searching for tool 'Qt6::qtprotobufgen' in package Qt6ProtobufTools.
-- Could NOT find Qt6ProtobufTools (missing: Qt6ProtobufTools_DIR)
CMake Error at qtbase/cmake/QtToolHelpers.cmake:605 (message):
  Failed to find the host tool "Qt6::qtprotobufgen".  It is part of the
  Qt6ProtobufTools package, but the package could not be found.  Make sure
  you have built and installed the host Protobuf module, which will ensure
  the creation of the Qt6ProtobufTools package.
Call Stack (most recent call first):
  qtbase/cmake/QtToolHelpers.cmake:55 (qt_internal_find_tool)
  qtgrpc/src/tools/qtprotobufgen/CMakeLists.txt:9 (qt_internal_add_tool)


Could we find a different way to handle this where it does not become a 
configure error for the top-level Qt build? Especially if we continue to add 
special-purpose modules it can become difficult to satisfy all host 
requirements for all modules.


Morten
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Mikołaj Boć as approver

[Morten Sørvig via Development]

Hello again,

Correct links to gerrit should be:

https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io<https://codereview.qt-project.org/q/owner:Mikolaj.Boc%40qt.io>
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io<https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%40qt.io>

(copy/paste error on my part :)

Morten

On 21 Dec 2022, at 15:21, Morten Sørvig via Development 
mailto:development@qt-project.org>> wrote:

Hi,


I’d like to nominate Mikołaj Boć as an approver for the Qt project.

Mikołaj joined the Qt Company earlier this year and hit the ground running. He 
has contributed features and many bug fixes for the Qt for WebAssembly platform 
integration, as well as bug fixes for other parts of Qt.

I trust him to be a good approver. Links to gerrit dashboards:

Patches: 
https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io<https://codereview.qt-project.org/q/owner:axel.spoerl%40qt.io>
Reviews: 
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io<https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%40qt.io>

(I’m a colleague of Mikołaj at the Qt Company where we are on the same team)

Regards,
Morten
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Mikołaj Boć as approver

[Morten Sørvig via Development]

Hi,


I’d like to nominate Mikołaj Boć as an approver for the Qt project.

Mikołaj joined the Qt Company earlier this year and hit the ground running. He 
has contributed features and many bug fixes for the Qt for WebAssembly platform 
integration, as well as bug fixes for other parts of Qt.

I trust him to be a good approver. Links to gerrit dashboards:

Patches: 
https://codereview.qt-project.org/q/owner:Mikolaj.Boc%2540qt.io
Reviews: 
https://codereview.qt-project.org/q/reviewer:Mikolaj.Boc%2540qt.io

(I’m a colleague of Mikołaj at the Qt Company where we are on the same team)

Regards,
Morten
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt for WebAssembly feature freeze exceptions

[Morten Sørvig via Development]

Hi all, 

We have two pending changes for the wasm platform which I'd like to request a 
feature freeze exception for:

* Adding the initial accessibility backend. This feature will initially 
be opt-in, and we are
  aiming to make it as non-disruptive as possible. A couple of details 
remains to be settled
 on the review.

* Updating the SDK to the latest Emcscripten version

(It’s a bit unclear which freeze policy (if any) applies to the SDK update. In 
any case it needs to be done.)

Morten
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development