HTML5 no wait syntax
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
I'll prepare a demo/input stack for the bug, so we can see IDE speed and standalone-speed both with dp9 (my current favourite) and dp14.
One thing I like very much in the UK is the disciplined "queuing" of people. This is most effective for the overall speed. So I'll go at the end of your queue, *just now*, and you'll have the demo until Monday.
One thing I like very much in the UK is the disciplined "queuing" of people. This is most effective for the overall speed. So I'll go at the end of your queue, *just now*, and you'll have the demo until Monday.
shiftLock happens
-
- Posts: 52
- Joined: Mon Jun 24, 2013 4:10 am
- Location: Hawaii
- Contact:
Re: HTML5 no wait syntax
Aloha, Peter...
At Hermann's suggestion I'm hopping over here. I usually "live and die" on the mailing.
Question: is Wait is disabled now in 8 LC 14? I'm getting a total failure on one stack that I think should run. I have 4 wait commands in different card scripts. I believe I can easily change those to send in time methods without much difficulty.
Side question: If the LiveCode team had *their* choice of LC use behaviors, would prefer to interact with us via these forums or the mailing lists?
As you know LC standalone seem to be failing completely in FFox 44... I'm standing by on that one.
At Hermann's suggestion I'm hopping over here. I usually "live and die" on the mailing.
Question: is Wait is disabled now in 8 LC 14? I'm getting a total failure on one stack that I think should run. I have 4 wait commands in different card scripts. I believe I can easily change those to send in time methods without much difficulty.
Side question: If the LiveCode team had *their* choice of LC use behaviors, would prefer to interact with us via these forums or the mailing lists?
As you know LC standalone seem to be failing completely in FFox 44... I'm standing by on that one.
Re: HTML5 no wait syntax
Yes, you need to use "send in time" for now, please. Sorry for the inconvenience. It's a really thorny problem that can only be solved fully by basically rewriting the LiveCode engine, so there will be workarounds in the short term. It's also blocking provision of usable "url" syntax, much to my frustration.Brahmanathaswami wrote:Question: is Wait is disabled now in 8 LC 14? I'm getting a total failure on one stack that I think should run. I have 4 wait commands in different card scripts. I believe I can easily change those to send in time methods without much difficulty.
I personally find it easier to interact with users via the mailing list, but I try to keep a reasonable overview of things that are relevant to me on the forums.Brahmanathaswami wrote:Side question: If the LiveCode team had *their* choice of LC use behaviors, would prefer to interact with us via these forums or the mailing lists?
That's a change in behaviour in Firefox interacting poorly with a non-standard piece of JS in the HTML5 engine, and there are already fixes queued for build in both Firefox and LiveCode.Brahmanathaswami wrote:As you know LC standalone seem to be failing completely in FFox 44... I'm standing by on that one.
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com
Re: HTML5 no wait syntax
It will be really useful to have something that can be used to quantify relative speed -- thank you.[-hh] wrote:I'll prepare a demo/input stack for the bug, so we can see IDE speed and standalone-speed both with dp9 (my current favourite) and dp14.
LiveCode Open Source Team — @PeterTBBrett — peter.brett@livecode.com
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
Now you have a notification about an answer in your *mail*Brahmanathaswami wrote:At Hermann's suggestion I'm hopping over here. I usually "live and die" on the mailing.
Hi Brahmanathaswami,
of course everybody should use what he likes (or likes more).
It was more a hint for appropriate information and an invitation to contribute to the subforum. Here your contributions have a better visibility ...
For me it is a good solution that some people use (with different weights) both, forum and use-list and 'connect' these. By that usually no important information for help is lost in the never ending stream of mailing lists.
Hermann
p.s. At first forced by the non-availibility of wait for HTML5 I meanwhile totally stopped to use it: Send <in time> is a wonderful tool, for more than avoiding waiting.
I miss only a substitute for forcing screen updates alike "wait 0 millisecs with messages".
shiftLock happens
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
Attached you'll find is a simplified TESTSTACK for comparisons between dp-releases.
Mainly tested (with timing measured) is
"send <in time>" and smoothness of "move ... without waiting".
The stack has an action every full next second, that is
It 'highlights' an appropriate item in a text field, that contains the constants zero, one, ..., nine in an order that is randomized every 10 seconds.
Check button 'Move' causes a move of the 'highlight' to the new target without waiting.
There is no accurate timing for that, it's more for testing the CPU load and for looking at an object that should move "smoothly" an arrive at full second.
These are the results I found with my tests.
This quotient will be about the same for slow to fast machines, that is roughly 15-20.
Tests above made on MacOS X 10.11.3, Mac mini 2.5 HGz, using locally browser Safari.
Mainly tested (with timing measured) is
"send <in time>" and smoothness of "move ... without waiting".
The stack has an action every full next second, that is
Code: Select all
on handler
...
send "handler" to me in 1000-(the millisecs mod 1000) millisecs
end handler
Check button 'Move' causes a move of the 'highlight' to the new target without waiting.
There is no accurate timing for that, it's more for testing the CPU load and for looking at an object that should move "smoothly" an arrive at full second.
These are the results I found with my tests.
- dp9 HTML5 standalone
9 ms (avg of 150). Using move 11 ms (avg of 150) - dp14 HTML5 standalone
190 ms (avg of 150). Using move 185 ms (avg of 150)
pauses sometimes for two to three seconds. - [dp-9 IDE: 1 ms (avg of 150), with move 1 ms (avg of 150)]
- [dp14 IDE 1 ms (avg of 150), with move 1 ms (avg of 150)]
This quotient will be about the same for slow to fast machines, that is roughly 15-20.
Tests above made on MacOS X 10.11.3, Mac mini 2.5 HGz, using locally browser Safari.
- Attachments
-
- testHTML5.livecode.zip
- Teststack 1: 'Send <in time>' and 'move'
- (2.82 KiB) Downloaded 272 times
shiftLock happens
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: HTML5 no wait syntax
Peter solved the speed-problem in 8.0.0-dp15 -- and didn't say a single word!!
Thank you very much Peter, and respect for that great work, now you gave us the speed you had in mind and announced.
Testing with the stack from my last post here, I got a new record with Firefox (and in average we are back to the dp9 speed).
dp15 HTML5 standalone (Firefox):
5 ms (avg of 150). Using move 5 ms (avg of 150) <-- Incredible result, try yourself!
dp15 HTML5 standalone (Chrome, Opera, Safari):
18-20 ms (avg of 150). Using move 20 ms (avg of 150)
Hermann
[Edit. Now It's correct, sorry. Had to repost for such a record!]
Thank you very much Peter, and respect for that great work, now you gave us the speed you had in mind and announced.
Testing with the stack from my last post here, I got a new record with Firefox (and in average we are back to the dp9 speed).
dp15 HTML5 standalone (Firefox):
5 ms (avg of 150). Using move 5 ms (avg of 150) <-- Incredible result, try yourself!
dp15 HTML5 standalone (Chrome, Opera, Safari):
18-20 ms (avg of 150). Using move 20 ms (avg of 150)
Hermann
[Edit. Now It's correct, sorry. Had to repost for such a record!]
shiftLock happens