Monday, January 14, 2013

emscripten-qt progress: faster, better, many Qt + C++ demos in your browser!


Probably my final update to my series of blogs about trying to get Qt ported over to the wonderful Emscripten, so that a Qt + C++ app can be compiled to Javascript and HTML5, and so run in a browser.


So, since last time: first of all, I've finally settled on the name "emscripten-qt" over "QtGui.js" - the latter is probably a bit more descriptive of what the project actually is, but the new name pays homage to the projects that actually do all of the clever stuff!


Secondly, performance is much improved: by undoing an earlier pessimisation of mine (wince) and by profiling and then compiling a bunch of select files with full optimisations (emscripten doesn't use inlining when it optimises as it can bloat the code, but some classes benefit from it hugely), I've managed to get the "colliding mice" demo running in Firefox at several frames per second, rather than several seconds per frame :) An experimental blitter (toggleable at run-time via a checkbox) often improves this even further.


Thirdly, keyboard support is now vastly improved, with shift, ctrl, actual punctuation chars etc now implemented.


Fourthly, there is now a demo page! Check them out here! I've mainly picked the most interesting ones, either visually or in terms of interactivity, but may add some of the more "boring" ones in due course. I'm especially fond of wiggly, scribble and textedit, which showcase how your emscripten-qt app can be made to interact with the rest of the webpage.

"textedit" - with PDF export!

There's also been a lot of work on writing some helpers to make some of the synchronous dialogs etc (which Javascript cannot handle) more easily ported to asynchronous ones, and on making drag-and-drog asynchronous instead of synchronous (enabling demos such as the puzzle demo.)

I still have a few odds and ends and a lot of documenting to do (especially a porting guide, which would additionally require me to document emscripten-qt-sdl, which has been invaluable for flushing out all of the problematic synchronous dialogs etc), but after that I'll leave it for a while and get back to working on Kate's Vim mode :)


Anonymous said...

The demo page return 500.

Anonymous said...

Really nice stuff ! Does it already work with Qt5 ?

Nikos Chantziaras said...

This is quite impressive. Qt code running in a browser! Many talked the talk before this, but AFAIK you're the first to walk the walk :-)

I suppose it's not possible to avoid fuzzy scaling when zooming-in in the browser though? Is it possible for JS to intercept the zoom request and instead enlarge the canvas rather than letting the browser scale it?

kripken said...

This is so, so awesome. Keep it up!

SSJ said...


Qt 4.8 only at the moment. It relies quite heavily on QWS, which I believe is removed in Qt 5 in favour of QPA, so I'm not sure how easy Qt 5 would be to port.


Well, there's also Qt for nacl (, but that takes a different approach :)

I'm not sure what you mean about the zooming stuff, but basically all rendering (believe it or not) is done pixel-by-pixel by Qt itself i.e. the browser doesn't do any of the zooming tricks you see in e.g. the chips demo. Or were you talking about something else ... ?


Thanks - same to you! :)

SSJ said...


Ah, I think I know what you mean - I think it might be possible in theory (provided that the browser's own zoom state is exposed to Javascript, which doesn't sound like something that would be available consistently across browsers, alas), but would likely require each app to be individually patched.

Anonymous said...

You are doing a great job here!

Anonymous said...

Two words: MIND-BLOWN! Very cool, really. Nice work.

Anonymous said...

What about QML and Opengl(webgl)?

SSJ said...


WebGL and QML support would be great to have, but to be honest I don't think that I personally will be tackling either in the foreseeable future :/

Javier Urien said...

This is Awesome!!

Please continue working on this!

Also, one question! How do you handle local file access? is it possible?


Really cool!

SSJ said...


Thanks :)

Currently file access is handled using emscripten's built-in pseudo-filesystem (see the "scribble" example). I see no reason why this couldn't be extended by using something like, for example, though :)

b10663r said...

Where did you get the idea for this?

SSJ said...


See my comments here :)

b10663r said...

Ah, thanks. I was recenlty having this same idea, though I wanted to have live, online QML demonstrator. Since Python and other languages have their own on-line editors with instant results.

How hard would that be? To have a QML code window and a output window?

SSJ said...


I'm not sure, but check out akreuzkamp's comment here. I said earlier that I wouldn't be pursuing QML and OpenGL support, but a recent unexpected development might change this - we'll have to wait and see :) If I do, I'll also tackle QtNetwork, too, though this will need some server support to get around the Same-Origin Policy. I have a very specific Qt app in mind that I'd love to get running in emscripten-qt :)

PiggZ said...

For showing off your great work, I challenge you to compile Scribus into a web app that can run on a Chromebook to allow desktop publishing on that OS ;)

SSJ said...


That would be cool as hell - I might just give that a try one day ;)

PiggZ said...

@ssj By next week would be great so my daughter can do her homework on her own computer ;)

SexyMimi said...

Well, I tested most of the demos and they all seem to work fine on Chromium, Rekonq and Opera (a little bit slower with Opera though) and they all consume pretty much the same amount of RAM.

I wonder if it is possible to add Javascript-based events to our applications ?
I'd really like to know if there is a way to use Qt as the front-end of a Rails application for instance. For experimental purposes.

SSJ said...


Woah - it works in reKonq? What version are you using? I'm using the one that comes with Kubuntu 12.04, and it doesn't support all of the typed arrays spec :/

emscripten-qt apps can use the standard feature of emscripten to communicate with Javascript:

For some concrete examples, check out the wiggly source (for calling Javascript functions from emscripten-qt, and vice-versa) and the corresponding Javascript (search for "editableText").

b10663r said...

@SexyMimi, in theory, yes. Witty from already does that.

Will said...

This looks amazing! I couldn't find i the docs whether or not the resulting Javascript is necessarily obfuscated, as the Asteroids demo source looks to be?

SSJ said...


When these demos were first prepared, the code was not really obfuscated by default, so I wrote a separate optimiser to do this.

Nowadays, upstream emscripten will at least do a kind of local variable obfuscation by default, and if asm.js is used, I believe it does both local and global obfuscation.

nemo said...

So, the portedasteroids demo says almost unusable in Firefox?
I tried both Firefox stable and nightly and it was fast, smooth. Quite responsive. I couldn't discern any difference in comparison w/ chromium.

Is this comment out of date?

SSJ said...


I've just played a couple of games on Firefox nightly, and you're right - it's definitely much smoother. I'll leave the comment there for a while, though, as not everyone is using an up-to-date Firefox. Hopefully, when the proper HTML5 Qt rendering backend lands in the not-too-distant future, it will be silky smooth everywhere. Fingers crossed :)

nemo said...

Well, as noted, latest *stable* firefox was also quite smooth.
Also I grabbed Firefox 18, and while it wasn't as smooth, it was still pretty darn playable. As in, smooth enough that the asteroids seemed to be tumbling normally, and stuttering was intermittent.

So, at present, comment seems pretty misleading and a bit of a downer for anyone looking into emscripten-qt. But, hey, whatev.

Oh. And almost forgot. This is pretty awesome and we might use it to try and avoid having to write a new frontend for our game :) We already have a cross-compile of the backend, just no nice frontend. Desktop frontend is qt.

SSJ said...


Ok - I've removed the warning :)

"Oh. And almost forgot. This is pretty awesome and we might use it to try and avoid having to write a new frontend for our game :) We already have a cross-compile of the backend, just no nice frontend. Desktop frontend is qt."

Cool - let me know how you get on!

Wilson Chen said...

It's really amazing. But I try the instructions you post in wiki. I got llvm link: error

How to fix it?! Thank you!

SSJ said...


Can you be a bit more specific? Is that the full error message, and at what step does it occur? emscripten can be a pretty fast-moving target, and the version I'm using at the moment is a few weeks old :/

Joseph Pea said...

@SSJ QML with WebGL accelerated rendering would the SH******T.