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." _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
