HTML5 deployment: progress comes into sight

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: HTML5 deployment: progress comes into sight

Bob Sneidar via use-livecode
Simply a creative contribution to this thread:

Here are direct links. Worth waiting for loading, it's faster than you
expect. (Also loading times has been essentially improved with my tests).

[EU] http://hyperhh.org/html5/LCImageToolboxHTML5-9.0.0-dp-4hhX.html
[US] http://hh.on-rev.com/html5/LCImageToolboxHTML5-9.0.0-dp-4hhX.html

The timing you see are the LC-times, not the screen update of the browsers
which is of course slower while a browser is caching large imageData.

Latest Safari and Chrome Canary (but not yet Chrome) are fastest with
the screen updates. Also tested to be OK here with latest Firefox and
latest Opera. As always: doesn't run in IE/Edge.

(It was tedious to work around the missing javascriptHandler in HTML5
deployment, we look forward to that feature Mark!)

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: HTML5 deployment: progress comes into sight

Bob Sneidar via use-livecode

> On Jun 2, 2017, at 3:02 PM, hh via use-livecode <[hidden email]> wrote:
>
> Simply a creative contribution to this thread:
>
> Here are direct links. Worth waiting for loading, it's faster than you
> expect. (Also loading times has been essentially improved with my tests).
>
> [EU] http://hyperhh.org/html5/LCImageToolboxHTML5-9.0.0-dp-4hhX.html
> [US] http://hh.on-rev.com/html5/LCImageToolboxHTML5-9.0.0-dp-4hhX.html
>
> The timing you see are the LC-times, not the screen update of the browsers
> which is of course slower while a browser is caching large imageData.
>
> Latest Safari and Chrome Canary (but not yet Chrome) are fastest with
> the screen updates. Also tested to be OK here with latest Firefox and
> latest Opera. As always: doesn't run in IE/Edge.
>
> (It was tedious to work around the missing javascriptHandler in HTML5
> deployment, we look forward to that feature Mark!)

Very inspirational work.


Best regards,

Mark Talluto
livecloud.io <http://livecloud.io/>
nursenotes.net <http://nursenotes.net/>
canelasoftware.com <http://www.canelasoftware.com/>

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: HTML5 deployment: progress comes into sight

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
Just getting back here after  a week away on another project where they are moving the Hinduism Today app to an HTML 5 platform

(shameless promotion) check it out… pretty cool  release (free) on the App store… Android version is buggy.

@ Roland: Right.. my use of "Syncronous" was  a bit off, more like asynchronous w/ wait  (see below)

@ HH Thank you. Your clarification is perfect, exactly our challenge, well defined.

I think the use cases are obvious: Assuming we want to

a)  "encapsulate" all the heavy lifting to "*models*.livecode" scripts that do the hard work
b) we use the browser widget as a canvas for views  small triggers.

you would want to be able to, for example have a user enter some year  (say date of birth) in a little browser widget form thing.

submit to the "model.livecode" script  and if they entered something stupid like

2620  instead of 2062

your data input validator would reply to the brower widget (which must somehow know to halt processing) and reply to the user

"Hey, No way you were born in 2620!"
-------
AND During development… let's say the user did enter 2062, it pass validation, but the model.livecode attempt to store it in the sqllite database fails because some error in your LC code… we need a feedback loop that can tell us exactly at one point in the JS execution the failure occurred.  because, who knows… maybe you passed a bad param in the JS..

Mark: check out my earlier business request… at the risk of starting a flame war over LC's attempts for revenues from the existing paid user base, "you all" might consider taken that dollar value quoted to me and posting is as a "reach goal"  You might find support.

BR:

FWIW  I will copy here : this is the distillation requirements  as sent back to me, since they detail some of the difficulty faced.

minus the $ value attached to quotation

----------
Requirements

Enhance the current browser handler feature, allowing LiveCode handlers called from JavaScript to return a value immediately to the calling code. This requires the LC handlers to be executed synchronously - the calling code will block until the LC handler completes and its value is returned.


Platforms

1)                       Android
JavaScript calls are executed on a separate thread owned by the WebView - getting a return value requires posting the handler execution request to the event queue, yielding to the engine thread, which must execute the handler and store the result in such a way that it is accessible once control is returned to the waiting WebView thread.


2)                       iOS & MacOS
May be the simplest to deal with - the handler callback is either executed on the engine thread, or may call a function to run code blocks on the engine thread. What will be required though is to modify the current scheme of posting a handler execution message on the event queue to execute the handler directly so the return value can be obtained

3)                       CEF
JavaScript calls are executed within the CEF render process, so calling LC handlers requires communicating with the main engine process. CEF provides an inter-process communication (IPC) mechanism, however it is designed only for asynchronous message sending so waiting for a return value or reply is not supported.

In order to provide synchronous execution of LC handlers, an alternative IPC mechanism will be needed that should not interfere with the existing CEF scheme. Named pipes are a good implementation candidate on both Windows and Linux, however they would need to be integrated into the event handling loops on both platforms.

4)                       Execution Restrictions (Optional)
Depending on the implementation, there may be some operations that are unsafe to call from within the executing handler. For the CEF implementation, this will almost certainly include access to browser properties that require communication with the render process. There are several other areas in the engine where certain classes of operation are prohibited, for example within a widget’s OnPaint handler any operations that use “wait” should be avoided. It may be useful then to implement a general purpose execution restrictions mechanism to throw an error in these situations rather than allow these risky operations to occur.

 
To implement items 1 to 3 the time estimate is about 14 days of work at a cost of $.... For the optional item 4 it would require another 8 days of work at …..$
 
--------------

 

On 5/31/17, 11:35 AM, "use-livecode on behalf of hh via use-livecode" <[hidden email] on behalf of [hidden email]> wrote:

    "Synchronous" means here that the callback is done in the order it appears in
    the list of js instructions, i.e. "synchronous to the instruction order".
   
    If you say in your js function
   
       instruction1;
       callback1;
       instruction2;
       callback2;
   
    then you can't control what's done first. This is the price we have
    to pay for speed (multi-threading).
    It is even possible that callback2 arrives at LC _before_ one of
           instruction1; callback1; instruction2;
    is finished.
    That's what Jonathan tries to have (successfully in some scenarios)
    by doing in the widget first
       instruction1; callback1;
    then, after getting callback1:
       instruction2; callback2;

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: HTML5 deployment: progress comes into sight

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
On 05/31/2017 02:35 PM, hh via use-livecode wrote:

> "Synchronous" means here that the callback is done in the order it appears in
> the list of js instructions, i.e. "synchronous to the instruction order".
>
> If you say in your js function
>
>     instruction1;
>     callback1;
>     instruction2;
>     callback2;
>
> then you can't control what's done first. This is the price we have
> to pay for speed (multi-threading).
> It is even possible that callback2 arrives at LC _before_ one of
>         instruction1; callback1; instruction2;
> is finished.

I had a similar need in PowerDebug in order to handle asynchronous
events over socket connections for remote debugging. And dealt with it
thusly:

Requests are sent asynchronously and trigger a callback message when
they're done. The callback message payload contains a reference to the
message that called it. That way a callback handler can associate the
returned message with the calling handler, and if needed a wait loop can
implement a procedural pseudo-synchronous call.

It's kind of the way session cookies work in a browser. It probably
won't work for every use case, but when I need to define a statement
order from asynchronous events it does the trick.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: HTML5 deployment: progress comes into sight

Bob Sneidar via use-livecode
Mark Wieder wrote:

    Requests are sent asynchronously and trigger a callback message when
    they're done. The callback message payload contains a reference to the
    message that called it. That way a callback handler can associate the
    returned message with the calling handler, and if needed a wait loop can
    implement a procedural pseudo-synchronous call.

Fascinating solution for X no of use cases, where you don't really need *now* , but where what you really only need is to know "exactly when and what" happened, even if slightly (typically, milliseconds) after the whole series events/statements finish

BR


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: HTML5 deployment: progress comes into sight

Bob Sneidar via use-livecode
On 06/03/2017 06:38 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

> Fascinating solution for X no of use cases, where you don't really need *now* , but where what you really only need is to know "exactly when and what" happened, even if slightly (typically, milliseconds) after the whole series events/statements finish

Also for pseudo-parallel processing:

if you have three asynchronous processes that need to finish before you
can move past a certain point in a script, you can set three flag
variables to false, then set each individually to true in its callback
handler, and loop on those three variables until they're all true or you
reach a timeout.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: HTML5 deployment: progress comes into sight

Bob Sneidar via use-livecode
No need to loop.

Set three flags to false. After each callback comes in and the flag gets switched, check all three flags. After the last ones comes in, all three flag variables will be switched and can trigger the next action.

Sent from my iPhone

> On Jun 3, 2017, at 9:04 PM, Mark Wieder via use-livecode <[hidden email]> wrote:
>
>> On 06/03/2017 06:38 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
>>
>> Fascinating solution for X no of use cases, where you don't really need *now* , but where what you really only need is to know "exactly when and what" happened, even if slightly (typically, milliseconds) after the whole series events/statements finish
>
> Also for pseudo-parallel processing:
>
> if you have three asynchronous processes that need to finish before you can move past a certain point in a script, you can set three flag variables to false, then set each individually to true in its callback handler, and loop on those three variables until they're all true or you reach a timeout.
>
> --
> Mark Wieder
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: HTML5 deployment: progress comes into sight

Bob Sneidar via use-livecode
On 06/04/2017 02:53 AM, Jonathan Lynch via use-livecode wrote:
> No need to loop.
>
> Set three flags to false. After each callback comes in and the flag gets switched, check all three flags. After the last ones comes in, all three flag variables will be switched and can trigger the next action.

Nice. That's probably a better way to do that.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: HTML5 deployment: progress comes into sight

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
Yet another creative contribution to this thread (beta version,
nowhere else linked for a few days).

http://hyperhh.org/html5/video-funHTML5-9.0.0-dp-4hhX.html

Video-Fun is a HTML5 standalone that communicates with the webpage
to take frames from a video and display them as image.
As we have an image and not a browser widget we can put everything
on top of it (here a digital clock) or even add some image effects
(blur, grayscale, posterize, rgb factors invert, duotone, flipH/V).

On a medium fast machine with a decent graphic card (for example
MacMini 2.5 GHz/IntelHD4000, Safari 10) we get _30 fps_ for the
display.

The sound is done by the video running in the webpage.

The timing display (for the overall actions) shouldn't go over
120 ms (if so try a faster/newer browser).



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
123