Nice overview, thanks Morten!
Tor Arne
On 6 Jun 2024, at 13:20, Morten Sørvig via Development
wrote:
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 deve
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 thing
Hi,
+1 to the emscripten upgrade.
The upgrade is version 3.1.14 -> 3.1.27, which includes a number of fixes which
are strongly desirable in 6.5.
Cheers,
David Skoland
On 13 Dec 2022, at 11:14, Morten Sørvig via Development
mailto:development@qt-project.org>> wrote:
Hi all,
We have two pendi
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 detai
Hi all,
Qt for WebAssembly shipped as a tech preview for 5.12, and for 5,13 we want to
fill in some of the missing pieces, and also make Q_OS_WASM a supported
platform. Supported here does not mean that everything that does not work today
will work, but rather that what we claim will work actua
Morten Sørvig (14 March 2018 10:54)
> (The alternative would be to wait it out - perhaps threading support will be
> enabled and stable in all browsers before we get to merge wip/webassembly).
>From recent discussion with a Firefox developer, I gather that browser
vendors are generally trying to r
I am personally quite excited about having a common standard for
binaries on the web, that can be generated from C++ and I think there is
a lot of potential and I am happy to see Qt going in that direction.
Regarding the load-times: WebAssembly supports dynamic linking, so
browsers might cache Qt
>> https://codereview.qt-project.org/181112
> not sure why anyone would want to stop/block execution of the one and
> only thread.
sleep() and friends do have a place in single threaded applications. You can
use them to do some backoff mechanism when waiting for an external event. You
shouldn't
On 03/14/2018 07:54 PM, Morten Sørvig wrote:
>
>> On 9 Mar 2018, at 13:57, Morten Sørvig wrote:
>>
>> * (No) thread support
>>
>> Wasm and Emscripten do have pthreads support. However this requires
>> SharedArrayBuffer,
>> which has been disabled in all major browser after recent security
> On 9 Mar 2018, at 13:57, Morten Sørvig wrote:
>
> * (No) thread support
>
> Wasm and Emscripten do have pthreads support. However this requires
> SharedArrayBuffer,
> which has been disabled in all major browser after recent security incidents.
>
> So we are looking to upstream a no-thr
> On 13 Mar 2018, at 15:27, Svenn-Arne Dragly wrote:
>
> I also think Qt for WebAssembly is exciting because it opens up the
> possibility to show a minimal demo of a full application in the browser.
> Instead of showing a video of the application on a product page, a small demo
> with limit
On 03/09/2018 03:53 PM, Jason H wrote:
While I am excited about this, I still wonder that it's the right approach. By
right, I mean scalable.
After evaluating the WebGL platform (which I was excited about as well) had
having extreme performance issues, I foresee that this will has performance
> On 13 Mar 2018, at 02:15, Jason H wrote:
>
>> On 03/12/2018 11:42 PM, Jason H wrote:
>>> 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js
>>> less so. I can't really argue much difference between WebAssembly and
>>> asm.js though, given asm.js's previous performance c
On 13/03/2018, 3.15, "Development on behalf of Jason H"
wrote:
>
>Sure. But how much refactoring is Qt going to accept without a commitment
> to the web agenda? How much prioritization will it be allowed? Will the Qt
> company
>support it as a real part of Qt? It's easy to say pat
> On 03/12/2018 11:42 PM, Jason H wrote:
> > 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js
> > less so. I can't really argue much difference between WebAssembly and
> > asm.js though, given asm.js's previous performance claims.
>
> In my experience WebAssembly is much m
On 03/12/2018 11:42 PM, Jason H wrote:
> 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less
> so. I can't really argue much difference between WebAssembly and asm.js
> though, given asm.js's previous performance claims.
In my experience WebAssembly is much more perfor
> Sent: Monday, March 12, 2018 at 7:29 AM
> From: "Morten Sørvig"
> To: "Qt Project Development Mailing-List"
> Subject: Re: [Development] Qt for WebAssembly
>
>
>
> > On 9 Mar 2018, at 19:09, Tim Murison wrote:
> > I'd also
> Oh, who knows what will happen. But there are indicators that this time
> may be different:
>
>1. WebAssembly is a web standard
>2. General support for web applications is getting better (e.g. service
> workers)
>3. Canvas-rendering web apps now exist (Google Sheets)
>4. Better
> On 9 Mar 2018, at 19:09, Tim Murison wrote:
> I'd also like to echo and hopefully amplify what Jason H said about
> qmlweb. IMO, this is the solution that Qt should be embracing and
> integrating upstream. qmlweb aims to do what Qt has always done, make
> cross-platform development easy, effic
> On 9 Mar 2018, at 15:53, Jason H wrote:
>
>
> I don't want to steal your thunder, but what is fundamentally different about
> this approach this time? Why will the results be any different?
Oh, who knows what will happen. But there are indicators that this time
may be different:
* Web
> Sent: Friday, March 09, 2018 at 3:05 PM
> From: "Tim Murison"
> To: development@qt-project.org
> Subject: Re: [Development] Qt for WebAssembly
>
>
> > Thanks Tim, I'm glad to know I'm not the only one. I *highly*
> > recommend the Wt toolkit
> Thanks Tim, I'm glad to know I'm not the only one. I *highly*
> recommend the Wt toolkit (https://www.webtoolkit.eu/widgets) , even
> if it's not LGPL. The Widget gallery is implemented in Wt, and you
> can see they have everything, and even a working TreeView! Your
> QWidget experience will tra
> Sent: Friday, March 09, 2018 at 1:09 PM
> From: "Tim Murison"
> To: development@qt-project.org
> Subject: Re: [Development] Qt for WebAssembly
>
> >
...
> >
>
> +1, I couldn't agree more with this sentiment.
>
> I work in softwar
Hi, I would like to add...
One of the guys over at https://qtmob.slack.com keeps a demonstration of
the Qt examples for Qt Webassembly (thanks David!):
https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/index.html
Not all of the examples work, and not all of them work correctly.
Firefox
>
> While I am excited about this, I still wonder that it's the right
> approach. By right, I mean scalable.
> After evaluating the WebGL platform (which I was excited about as
> well) had having extreme performance issues, I foresee that this will
> has performance issues as well, because of one
;also-ran" situation.
I don't want to steal your thunder, but what is fundamentally different about
this approach this time? Why will the results be any different?
> Sent: Friday, March 09, 2018 at 7:57 AM
> From: "Morten Sørvig"
> To: "Qt Project Developme
Hi all,
As you may have noticed work on Qt for WebAssembly is underway. With the
recent updates the wip/webassembly branches are now based on Qt 5.11, which
they will continue to be while we work on bringing up Qt Quick. The tracking
bug for the project is QTBUG-63917 (with subtasks). This is a co
27 matches
Mail list logo
