On 01/09/2013 04:17 PM, Jason H wrote: > You bring up a good point. Maybe the output is JS to the web browser. > And I think that is a more awesome solution - because then your > deployment platform does not need to support Qt. While I originally > conceived of this to introduce people to QML I ran into another idea. I > have a Samsung SmartTV which has a HTML5/Webkit app development > environment. If Samsung supported WebGL (which they might, I haven't > checked) we could write apps for Samsung TV but run them off a remote > server. The code on the server would be QML, and we could target any > WebGL compliant platform. > > I don't think performance is that critical. If it was they wouldn't be > running it in a browser. ;-) > > The problem with NaCL is you have to wait and download the entire > binary. Meanwhile if you just spit out JS/WebGL commands there is no > transfer time.
Well, streaming of JS/WebGL still sounds a bit dubious. Do you force the browser to reevaluate a bunch of JS for each frame? If it's at the QPA level you either need to make a paint engine that generates JS (meaning QML 2 and the scene graph is out), or you have to hook in with a OpenGL library that proxies GL rendering commands (and texture uploads etc) into JS/WebGL. Both but especially the latter would be tons of work. -- Samuel _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
