Thought for improving the speed of the HTML 5: Will it work?

Bringing your stacks to the web

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Thought for improving the speed of the HTML 5: Will it w

Post by monte » Fri Nov 06, 2015 9:53 pm

@-hh Regarding externals I haven't yet investigated the possibility of compiling to JavaScript. I suspect I would need considerable hand holding from @peter-b or @lcmark in order to achieve that. My understanding though is there are or will be JavaScript hooks so we can use the millions of JavaScript libraries which is probably simpler.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: Thought for improving the speed of the HTML 5: Will it w

Post by [-hh] » Fri Nov 06, 2015 10:23 pm

@monte
As this is still somehow in the sense of the OP's (William) thoughts:
I don't understand, didn't test, how externals work here.
Are they
  • read in to LC and then compiled to js by emscripten (and read again in by the HTML5-engine)?
  • added as somehow ready-made "js-externals" and read in by the HTML5-engine?
Could you explain that please?
It is possible to have a hardware accelerated Webkit browser compiled with emscripten ( trevorlinton.github.io/ ).
Does this imply, one could compile virtually any component of WebKit/Chrome etc. with emscripten and add this as a "plugin" to the HTML5 engine?
shiftLock happens

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Thought for improving the speed of the HTML 5: Will it w

Post by monte » Fri Nov 06, 2015 11:29 pm

@-hh I'm sorry I haven't spend more than the time it took to write the previous post thinking about externals for HTML5. Are the standard externals included in HTML5?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Thought for improving the speed of the HTML 5: Will it w

Post by FourthWorld » Sat Nov 07, 2015 1:31 am

[-hh] wrote:@Fourthworld
I misunderstood some of your arguments, sorry. You misunderstood some of mine too?
The discussion is about using very elementary
= copy/paste and get/set clipboardData["..."]
= (or more general) get/put into URL (...)
of LC by user interaction. Of course nobody here wants to have the ability to add SPAM or harmful compiled code to the system clipboard.
Yes, misunderstandings are likely on my part given how little time I've had to experiment with LC's HTML5 delivery thus far. I tend to be somewhat paranoid about open Internet systems like the Web, so the thought of having LC externals runnable from the JavaScript version of the engine makes me queasy, apparently unnecessarily so since it wouldn't seem that's no more possible than it would be desirable.

So back to copy/paste:

One thing I haven't tried is copying data from a LiveCode field in the browser. My hunch would have been that Cntl-C would simply invoke the browser's Edit->Copy command and thus work as expected, but the more I think about it the more I wonder if the "stack" is rendered into an HTML canvas object and perhaps in a way that makes it operate outside the purview of the browser's built-in copy/paste commands.

I haven't spent enough time with the canvas object to have a field for how editable text works in it, so input here from someone more experienced with it will help.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

peter-b
Posts: 182
Joined: Thu Nov 20, 2014 2:14 pm
Location: LiveCode Ltd.

Re: Thought for improving the speed of the HTML 5: Will it w

Post by peter-b » Sat Nov 07, 2015 2:11 am

Due to the way that the LiveCode engine currently works on HTML5, there are no externals (nor support for creating them) and it's unlikely that any way to do this will be added before LiveCode 8 is released.

My guess is that "traditional" externals for HTML5 just won't exist, and extending the HTML5 engine will be performed only using LiveCode Builder extensions (one we figure out how to call browser JavaScript APIs from LiveCode Builder code). I think that's a feature that will be coming in 8.1.0. For 8.0.0 the current plan is to get the "core" functionality of the LiveCode engine working properly -- there are a lot more important features missing, like "wait".

As far as copy & paste is concerned, the security issues that browsers are worried about is mostly that innocent-looking web pages could monitor the system clipboard for anything that looks like a password and send it to their nefarious masters. Although that is also a worry for normal applications, users are accustomed to regularly visiting "dodgy" websites and expecting their browser to protect them, whereas they are generally getting quite good at being careful what they install. This is why browsers don't currently have super convenient support for copy & paste. The clipboard support that's reliably available in browsers is *extremely* limited to specific tasks (such as adding text to text entry controls or contenteditable elements) and isn't generally made visible to JavaScript code in a useful way. As Mark mentioned earlier, there's a standard under development for JavaScript clipboard interaction and we're going to be monitoring it closely over the next few months to see how it's adopted by browsers.

System clipboards are horrible and scary no matter what system you're working on -- just ask Fraser, who's spent the last month submerged in the murky depths of clipboard support code. Sadly, there's nothing "elementary" about implementing "the clipboardData", or I would have done it already. I'd be very happy to accept patches from anybody who's too impatient to wait for me to get round to working on it myself. There would be no benefit whatsoever to trying to implement it in an external (indeed, I'm not sure it's actually possible).

The "get / put URL" stuff is going to work before LiveCode 8.0.0 is released, because it's obviously a critical feature. The current cause of "get url" will be fixed by getting "wait" working (the same technical problems underlie both issues), and once that's addressed, adding "put url" is straightforward.

Finally, we are currently looking into making the HTML5 engines available to use on your web pages via a global CDN, which should help with the "fast downloading & caching for the engine" issues. No guarantees, though -- we're still investigating.
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Thought for improving the speed of the HTML 5: Will it w

Post by monte » Sat Nov 07, 2015 3:19 am

Good stuff with the CDN. Will that allow caching of the mem file as I couldn't get safari to cache it
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: Thought for improving the speed of the HTML 5: Will it w

Post by [-hh] » Sat Nov 28, 2015 10:29 pm

Just wanted to add this info.

The new LC Guide (use Dictionary tab) contains a valuable hint for improving download speed dramatically.
LC-team wrote:Advanced: Speeding up engine download
Currently, the engine files are almost 30 MB, which is a lot to download before the engine can start. It is possible to speed up the download by enabling deflate compression in the web server configuration.
Enabling deflate compression reduces the total download size to around 6.3 MB. It's recommended to pre-compress the engine with gzip, and then configure your web server to serve the pre-compressed files.
For the Apache web server, configure mod_deflate to serve pre-compressed content. For the NGINX web server, add gzip_static on; to your configuration.
So this is the way if you run your own server.
If you have your files on the server of a provider you can try with the following addition to your ".htaccess"-file.

Code: Select all

<IfModule mod_deflate.c>
     <FilesMatch ".*\.(html|xml|php|css|js|mem|zip)$">
       SetOutputFilter DEFLATE
     </FilesMatch>
     AddOutputFilterByType DEFLATE application/rss+xml
     AddOutputFilterByType DEFLATE application/xml application/xhtml+xml
     AddOutputFilterByType DEFLATE application/javascript application/x-javascript
</IfModule>
I did it and it works really good:
If you try two or three files from my examples in thread "Succesful test" and have a medium fast connection (say 12 MBit) then you can have the standalones ready in less than one minute, with a fast connection in 5-20 seconds.

Happy weekend all.
shiftLock happens

malte
Posts: 1098
Joined: Thu Feb 23, 2006 8:34 pm
Location: Ostenfeld germany
Contact:

Re: Thought for improving the speed of the HTML 5: Will it w

Post by malte » Mon Nov 30, 2015 1:57 pm

Moin Hermann,

awesome that you point this out, as this really makes a difference! Now if you could quickly explain what you did to get a nicer progress bar I would be really really grateful! (as in, what did you need to change to display a different progress bar)

All the best,

Malte

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: Thought for improving the speed of the HTML 5: Will it w

Post by [-hh] » Mon Nov 30, 2015 3:59 pm

Moin Malte.

The loading progress measuring and animation within a custom html page
(that calls one's HTML5-standalones).

Let me describe it in such a way that not only you but also beginners with HTML may use it.
  1. Download pace (download link at top right) http://github.hubspot.com/pace/
    It's also worth to look at the demos there so that you can see what you will have — wonderful.
  2. Unzip it and put at least
    = the file pace.min.js
    = the content of the folder themes
    into your 'CSS folder', which is often named "stylesheets".
  3. Add these three lines to the <head> section of your calling html page.
    Choose colour (here 'blue') and theme (here 'pace-theme-loading-bar.css')
    from the existing ones, look in the folder themes.

    Code: Select all

    <!-- reference (and reverence) to pace: http://github.hubspot.com/pace/ !-->
    <script src="./stylesheets/pace.min.js"></script>
    <link href="./stylesheets/blue/pace-theme-loading-bar.css" rel="stylesheet" />
    (See my example below, I didn't test this with the html page produced by the standalone because it is too large to use it as example here).
Now one could use the following as a template (I put some minimal HTML5-valid styling for your tests into that). You could name this standalone-calling webpage as you like (for example) "animationengine-<LCversion>.html".

It should reside, as I use it, in the same folder as the large standalone.js and the standalone.mem file, that's why you have to rename your "standalone.zip".

Note. All loading progress measuring and display is done by the brilliant PACE script.

Code: Select all

<html lang="en">

<head>
<meta charset="utf-8">
<title>Malte's AnimationEngine</title>
<!-- reference and reverence to pace: http://github.hubspot.com/pace/ !-->
<script src="./stylesheets/pace.min.js"></script>
<link href="./stylesheets/blue/pace-theme-loading-bar.css" rel="stylesheet" />
</head>

<body style="background-color:#CCC; color:#00F;
      padding:1em; margin:auto; width:80%;
      font-family: Arial,Verdana, sans-serif; ">
<header>
<h3>Animation Engine HTML5 Demo</h3>
</header>

<div>
<canvas id="canvas" oncontextmenu= "event.preventDefault()" style="outline:none;"></canvas>
<script type="text/javascript">
var Module = {canvas: document.getElementById('canvas')};
Module.livecodeStandalone = "<standaloneName>.zip";
</script>
<!-- one of the following two lines, adjust carefully the version !-->
<!--<script
  async type="text/javascript" src="standalone-commercial-8.0.0-dp-9.js"></script> !-->
<script
  async type="text/javascript" src="standalone-community-8.0.0-dp-9.js"></script>
</div>

<footer> <!-- Adjust to a personal link !-->
<p> [Made by <a target= "_blank"  href=" http://www.derbrill.de">Malte</a>]
[Made with <a target= "_blank"  href=" http://livecode.com/download">LiveCode</a>]</p>
</footer>
</body>

</html>
Hermann
shiftLock happens

Richard K. Herz
Posts: 20
Joined: Sun Apr 14, 2013 6:38 pm
Contact:

Re: Thought for improving the speed of the HTML 5: Will it w

Post by Richard K. Herz » Mon Nov 30, 2015 5:00 pm

Beautiful work [-hh]! This rekindles my interest in LC web apps!
[-hh] wrote:Meanwhile the answer to the question of the original post is

YES, IT WORKS.

...snip...

You may test it it here (from extern server).
First load two different modules in a row.
Then use the frameset of three rows and load by quick clicks three other modules.
Rich Herz
LiveCode work at ReactorLab.net

Richard K. Herz
Posts: 20
Joined: Sun Apr 14, 2013 6:38 pm
Contact:

Re: Thought for improving the speed of the HTML 5: Will it w

Post by Richard K. Herz » Tue Dec 08, 2015 5:32 pm

I am interested in what affects LC web app download speeds. I am located in San Diego, California, US and have my files posted on the On-Rev server, which is in Scotland, I think (10 time zones away). In San Diego, I can test from several places: (1) desktop on a fast wired connection at my university, (2) laptop at home on AT&T home consumer network connection paying for middle of 6 levels of throttling, and (3) virtual machine at my university viewed by laptop at home.

The fastest download and open speed I have seen is about 40 seconds or so, and that can be obtained in morning my time on all three connections. The slowest download and open speed I have seen is over 3 minutes, which is in evening my time at home from laptop on home consumer network connection. At that time, download speeds to virtual machine at university are about the same as earlier in the day.

Tests at http://www.speedtest.net show that download speeds slow down with distance between client and server. Round-trip ping times increase almost linearly with distance. There are other factors including differences between servers in one city. Download speed tests using http://www.speedtest.net to download from a server in Aberdeen, Scotland to client in San Diego are about the same as earlier in the day (5 Mbps) and at all three of my test clients. Presumably those tests use small files.

One hypothesis is that the slowdown in the evening to my home is due to "last mile" bottle neck (or deliberate throttling?) of large files to my home, since other speeds don't change significantly. That's my problem, not a general one.

Forgetting that problem, the fastest speeds - about 40 seconds or so - from Scotland to 10 time zones away is too slow to keep a user at the web site, I think. Unless other techniques can be used (CDN, segmenting engine, or entertaining user in some manner), it may be necessary to host files geographically close to users. When users are all over the globe, that would require multiple hosting sites and a method to direct users, or the browser, to the closest host.
Rich Herz
LiveCode work at ReactorLab.net

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: Thought for improving the speed of the HTML 5: Will it w

Post by [-hh] » Wed Dec 09, 2015 2:00 am

Rich,

perhaps one should denote for such comparisons also

= what is the OS and the (newest) Browser used
= what is roughly the hardware used.

These items will have some influence on the total time needed for 'download and display'.

In order to have a good base for comparisons when distances are in the focus I found a good query for WolframAlpha and made a widget of that, one can find this HERE (on-rev).
Sometimes it claims (incorrectly) to have an invalid input. If so, then click at the bottomRight icon that links with a correct query directly to WolframAlpha.

The default is the distance from Edinburgh to San Diego and 'direct' travel times of aircraft, sound and light in fiber.
Very interesting to know the maximum possible speed of a digital connection to the LC-mothership in Edinburgh.

Hermann
shiftLock happens

Richard K. Herz
Posts: 20
Joined: Sun Apr 14, 2013 6:38 pm
Contact:

Re: Thought for improving the speed of the HTML 5: Will it w

Post by Richard K. Herz » Wed Dec 09, 2015 7:01 am

Hermann,

Fun widget you made with WolframAlpha! I usually think of flying past New York to get to London but your widget map reminded me of looking down at Hudson's Bay, or at least Newfoundland, when flying over Canada.

Ping round trip time to Great Britain was about 160 ms using http://pingtest.net, or 80 ms one-way. That is compared to widget saying fastest possible speed - speed of light in vacuum over shortest route - is 28 ms. So actual ping trip takes three times as long as minimum possible time.

You are right about needing to quote OS, browser and hardware when reporting tests. At my end, browser was Chrome. OS was Mac from home and Win 7 at university.

However, I think the controlling factor in my tests was the 8000+ km distance during the day and, during the evening in San Diego, the "last mile" bottle neck to my house when neighbors get home and start watching Netflix and youtube.

Thanks
Rich
Rich Herz
LiveCode work at ReactorLab.net

[-hh]
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2262
Joined: Thu Feb 28, 2013 11:52 pm
Location: Göttingen, DE

Re: Thought for improving the speed of the HTML 5: Will it w

Post by [-hh] » Thu Dec 10, 2015 12:54 am

Until today I thought LC-com were doing it's own webhosting. Now I learned that it is a "service on top-of-the-line systems in a state-of-the-art data center" (on-rev-FAQs).
Actually they are using OVH SAS (Roubaix, France). This was in 2014 "The World's Worst Spam Support ISPs" in the Spamhouse-list, in 2015 it is not among the top ten any more.

Of course the service is rather specialzied and good and reseller prices are fair ones.
So we're coming closer to the time-eating "hops" when downloading from on-rev:

Unix-tools give a good measuring of time and routes. On Mac we can use for example "ping" and "traceroute" of "Applications/Utilities/Network Utilities". Or use, as others, the shell ('terminal').
  • Ping gives us with the network address "on-rev.com" for 10 pings the min,max,avg and stddev of the 'round-trips'. Interesting is here also the percentage of packet loss and the number 64-ttl = number of 'hops' (= 7 for me).
  • The num of 'hops' we see again with their addresses in lines when using traceroute to "on-rev.com".
    I have 7 hops and the two last before on-rev.com are from OVH (vss ... .ovh.net).
    The geoIP place given for on-rev.com (37.59.205.90) is Roubaix/France.The times of each of the 'hops' shouldn't be over-interpreted but are good to detect bottle necks by large deviations from the mean.
If anybody wishes to compare, here are my results using "Network Utilities"
[MacOS 10.11.2/ Mac mini 2.5 GHz/ WLAN 802.11n (-67 dBm) after a private 50 MBit DSL].

Code: Select all

Traceroute has started…

traceroute to on-rev.com (37.59.205.90), 64 hops max, 72 byte packets
 1  ... 2.269 ms  0.984 ms  1.829 ms
 2  ... 12.042 ms  12.597 ms  12.450 ms
 3  ... 24.630 ms  20.988 ms  23.720 ms
 4  ... 17.723 ms  20.199 ms  17.855 ms
 5  ... 26.245 ms  26.403 ms  25.985 ms
 6  vss-10a-6k.routers.ovh.net (178.33.100.204)  37.368 ms  26.140 ms  46.409 ms
 7  on-rev.com (37.59.205.90)  26.231 ms  25.620 ms  25.228 ms

Ping has started…

PING on-rev.com (37.59.205.90): 56 data bytes
64 bytes from 37.59.205.90: icmp_seq=0 ttl=57 time=25.665 ms
64 bytes from 37.59.205.90: icmp_seq=1 ttl=57 time=26.350 ms
64 bytes from 37.59.205.90: icmp_seq=2 ttl=57 time=55.359 ms
64 bytes from 37.59.205.90: icmp_seq=3 ttl=57 time=26.030 ms
64 bytes from 37.59.205.90: icmp_seq=4 ttl=57 time=25.732 ms
64 bytes from 37.59.205.90: icmp_seq=5 ttl=57 time=25.800 ms
64 bytes from 37.59.205.90: icmp_seq=6 ttl=57 time=26.325 ms
64 bytes from 37.59.205.90: icmp_seq=7 ttl=57 time=26.148 ms
64 bytes from 37.59.205.90: icmp_seq=8 ttl=57 time=25.537 ms
64 bytes from 37.59.205.90: icmp_seq=9 ttl=57 time=25.399 ms

--- on-rev.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 25.399/28.834/55.359/8.847 ms
My distance to Edinburgh/Scotland is 993 km (617 mi) and to Roubaix/France is 482 km (299 mi).

Would be interesting how many hops others have, from different parts of the USA?
And someone from Austria, England, France, Italy, Netherlands, Scotland, Switzerland, ... ?

[Edit: Changed GeoIP info according to info of Rich.]
Last edited by [-hh] on Thu Dec 10, 2015 4:30 am, edited 1 time in total.
shiftLock happens

Simon
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3901
Joined: Sat Mar 24, 2007 2:54 am
Location: Palo Alto

Re: Thought for improving the speed of the HTML 5: Will it w

Post by Simon » Thu Dec 10, 2015 1:37 am

Here are mine from Northern California

Code: Select all

Traceroute has started


traceroute to on-rev.com (37.59.205.90), 64 hops max, 72 byte packets
 1  ... 3.997 ms  1.832 ms  1.656 ms
 2  ...  15.405 ms  15.235 ms  11.191 ms
 3  ...  11.050 ms  11.114 ms  10.512 ms
 4  ...  10.967 ms  11.936 ms  20.399 ms
 5  ...  20.560 ms  10.123 ms  10.997 ms
 6  ...  37.511 ms  36.408 ms  37.250 ms
 7  ...  44.905 ms  44.318 ms  40.858 ms
 8  ...  69.029 ms  62.426 ms  61.808 ms
 9  ...  61.028 ms  62.449 ms  62.819 ms
10  ...  82.589 ms  83.176 ms
11  ...  82.425 ms  82.861 ms  81.765 ms
12  ...  510.075 ms  513.794 ms  514.766 ms
13  ...  171.561 ms  174.780 ms  187.778 ms
14  vss-10a-6k.routers.ovh.net (178.33.100.204)  167.085 ms  167.727 ms  163.500 ms
15  on-rev.com (37.59.205.90)  174.423 ms  164.753 ms  168.486 ms

Ping has started


PING on-rev.com (37.59.205.90): 56 data bytes
64 bytes from 37.59.205.90: icmp_seq=0 ttl=45 time=170.324 ms
64 bytes from 37.59.205.90: icmp_seq=1 ttl=45 time=162.941 ms
64 bytes from 37.59.205.90: icmp_seq=2 ttl=45 time=174.679 ms
64 bytes from 37.59.205.90: icmp_seq=3 ttl=45 time=175.366 ms
64 bytes from 37.59.205.90: icmp_seq=4 ttl=45 time=166.481 ms
64 bytes from 37.59.205.90: icmp_seq=5 ttl=45 time=167.332 ms
64 bytes from 37.59.205.90: icmp_seq=6 ttl=45 time=177.117 ms
64 bytes from 37.59.205.90: icmp_seq=7 ttl=45 time=192.114 ms
64 bytes from 37.59.205.90: icmp_seq=8 ttl=45 time=165.296 ms
64 bytes from 37.59.205.90: icmp_seq=9 ttl=45 time=165.595 ms

--- on-rev.com ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 162.941/171.725/192.114/8.195 ms
Horrible

Simon
I used to be a newbie but then I learned how to spell teh correctly and now I'm a noob!

Post Reply

Return to “HTML5”