Hi all,
We've had experimental HTML5 deployment available in several "Developer
Preview" releases of LiveCode 8 so far, and I thought you might like an
update on the status of the HTML5 engine and our current plans for it.
Recent changes
--------------
The most recent work that Fraser and I have done on HTML5 deployment has
been:
* Adding deployment from LiveCode Business edition and LiveCode Indy edition
* Improving font metrics and rendering
* Enabling support for "wait" syntax -- as part of this work, the HTML5
engine got a lot slower (see below)
* Enabling logging to standard output and standard error
* Porting our testsuite to (mostly) run in a browser
Current plans
-------------
Before LiveCode 8.0.0 is released, I hope that I can:
* Make the HTML5 engine faster again
* Make most "url" chunk syntax work
Once those two things are complete, then I plan to discuss with the
people who are using the HTML5 deployment and see what issues are most
affecting them in order to decide what to do next!
Why is the engine so slow since 8.0.0 DP 11?
--------------------------------------------
As you may know, we use the Emscripten C++-to-JavaScript to compile the
LiveCode engine so that it runs in a web browser. One of the
interesting things about JavaScript is that functions aren't allowed to
block, i.e. stop running and wait for something to happen. In LiveCode,
and in C++, this is very common! For example, if you write:
get url "https://livecode.com/";
put the number of lines in it
Then you know that the first line will make LiveCode stop and wait until
all of the data of our home page has been received over the network,
which might take quite a long time.
To get around this, we use a technology called Emterpreter, which is
part of the Emscripten compiler. Normally, the engine C++ code is
compiled to a specially optimised dialect of JavaScript called "asm.js",
which can be run directly (and very quickly) by a web browser. When a
C++ function is compiled with Emterpreter, however, it compiles to a
special bytecode that's run by a bytecode interpreter written in JavaScript.
Emterpreter helps get around the "blocking" problem because the bytecode
interpreter can save the state of the program and quit. Later, when
something happens, it can load up the previously saved program state and
start running it again. However, every function that can block -- and
every function that can possibly call a function that blocks -- must be
compiled with Emterpreter. Also, the bytecode interpreter is up to 22x
slower than running asm.js code.
To make "wait" syntax work, I had to compile most of the LiveCode script
evaluator using Emterpreter instead of compiling it to asm.js. Needless
to say, this makes running *any* script much slower!
Currently, Mark Waddingham and I are trying to figure out if it's
possible to put *both* versions of the engine functions into the HTML5
engine -- the slow, "wait"-compatible version, and the fast asm.js
version. Needless to say, this will make the engine source file (even)
bigger, but on the other hand, it would provide an engine that both
supports "wait" (and, importantly, "url" chunks) while also running code
that doesn't need to block nice and quickly.
It remains to be seen whether I can figure out how do that. ;-)
Peter
--
Dr Peter Brett <peter.br...@livecode.com>
LiveCode Open Source Team
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
