[Interest] Bringing Qt, C++ To The Web

Yves Bailly yves.bailly at sescoi.fr
Thu Jan 17 15:44:18 CET 2013


Le 17/01/2013 15:31, Jason H a écrit :
> You all are doing it wrong!!!
>
> I've been researching this a week or so. Emcripten is not going to work. You do not want your binary
> transalted to JS. The demos are slow, and regardless of optimization will always be slow. 4MB of
> compressed javascript for a program? Not with the bandwidth we have. And nevermind textures!
>
> If you want to make Qt5 web-able, what you need is a way to directly translate the OpenGL calls of
> Qt5's QML to WebGL.
> The barrier there is not "hard" however I am out of my element. I am not a GL person, though I have a
> basic understanding. What is needed is a http server, your binary and a translation layer to WebGL.
> The translation layer would make whatever textures needed available. These should be cached on the
> client in HTML5 storage.  Then it is only a small amount of commands that are easily executed that
> create each frame.

What you describe seems close to Wt: http://www.webtoolkit.eu/wt

However the use of "emscripten" is not so wrong: it can come as a very handy, short-term
and quickly-done solution. And there is probably still much room for optimizations, making
it even less slow. By the way, "slow" is a relative idea: clicking a button triggers an
action in 1ms on a desktop, 10ms through Emscripten: no big deal, from a user's view
it's almost the same even though it's 10 times slower.

About bandwidth, for me (at home) 4MB is "only" 3-4 seconds away,
so no big deal, and such bandwidth is more and more common.

Granted, it's far from ideal-perfect, but "all wrong" is a bit over.

-- 
      /- Yves Bailly - Software developper  -\
      \- Sescoi R&D  - http://www.sescoi.fr -/
"The possible is done. The impossible is being done. For miracles,
thanks to allow a little delay."



More information about the Interest mailing list