WebAssembly Target

classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

José Mejuto
El 16/03/2017 a las 16:27, Graeme Geldenhuys escribió:
> On 2017-03-16 14:45, Karoly Balogh (Charlie/SGR) wrote:
>> I think there's still a master switch to disable this in the browsers.
>
> So far Firefox 52 has none. Not in the Preferences, and not in
> about:config either.

Hello,

about:config

javascript.options.wasm;true/false


--

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Graeme Geldenhuys-6
In reply to this post by Michael Van Canneyt
On 2017-03-16 15:39, Michael Van Canneyt wrote:
> It should be opposite. Start with very tight security, and loosen up if
> deemed safe...

Yes, that definitely is a much better way to go.

Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Graeme Geldenhuys-6
In reply to this post by José Mejuto
On 2017-03-16 15:48, José Mejuto wrote:
> about:config
>
> javascript.options.wasm;true/false


Thanks for correcting me, my bad. I search for "assembly", "webassembly"
and also looked under "security.*"


Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

wkitty42
In reply to this post by Graeme Geldenhuys-6
On 03/16/2017 06:56 AM, Graeme Geldenhuys wrote:
> On 2017-03-11 23:23, Daniel Gaspary wrote:
>> I was reading about the new Firefox making WebAssembly publicly available
>> ("On Tuesday Firefox 52 became the first browser to support WebAssembly
>
>
> My system (FreeBSD) is compiling Firefox 52 in the background as we
> speak. I’m very curious to see how the Zen Garden demo runs here.
>
>   https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html

is this a takeoff from the movie AVATAR where they go up to choose their flying
lizard creature?


--
  NOTE: No off-list assistance is given without prior approval.
        *Please keep mailing list traffic on the list* unless
        private contact is specifically requested and granted.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

noreply
In reply to this post by Mattias Gaertner
On 2017-03-16 08:35, Mattias Gaertner wrote:

> On Thu, 16 Mar 2017 14:07:51 +0100 (CET)
> "Karoly Balogh (Charlie/SGR)" <[hidden email]> wrote:
>
>> [...]
>> Also, WebAssembly is a descendant of asm.js,
>
> Maybe historically. Technically asm.js is higher lvl than webassembly.
>
>
>> which was basically striped
>> down Javascript with some integer/pointer type tagging. As far as I
>> know,
>> the main problem with JS from a computing point of view, that it
>> handles
>> all numbers as floats for "simplicity", but with some code in other
>> languages, this can have real side effects (for example some integers
>> cannot be exactly expressed as floats,
>
> JS uses Double, which can express integers correctly from
> -$10000000000000 to $fffffffffffff.
> That should be enough for most browser programs, don't you think?
>

Well I used to think 32 bit integers were good enough for everyone, but
now I wish that all our integers went on to infinity, as some clever
person probably wants to create some program you never dreamed of that
will hit the integer limit...

But for dumb things like web stores, blogs... Yes.

For some physics simulation that is a massive number cruncher "no
integer is ever big enough"...

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Michael Van Canneyt
In reply to this post by Michael Schnell


On Thu, 16 Mar 2017, Michael Schnell wrote:

> On 15.03.2017 17:58, Karoly Balogh (Charlie/SGR) wrote:
>> Well, "degree of success" is relative, ...
>
> Anyway, it's great to know that you are watching the proceedings
> regarding WebAssembly, and already did some effort to get started !!!!
>
> Just for enhancing your motivation :-) (of course this issue is more
> like a project related to the Lazarus or mse designers, but you are
> going to pave the way) :

The way is already paved.

In fact, there is an alternate approach, transpiling pascal to Javascript.

It's much farther ahead than the webassembly target, already produces
programs running in the browser and the first web-based components are
already being developed using this approach.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Karoly Balogh (Charlie/SGR)
Hi,

On Fri, 17 Mar 2017, Michael Van Canneyt wrote:

> In fact, there is an alternate approach, transpiling pascal to Javascript.
>
> It's much farther ahead than the webassembly target, already produces
> programs running in the browser and the first web-based components are
> already being developed using this approach.

I believe these will be complimentary solutions in the end, one will be
better for certain things than the other, with a lot of overlap, of
course. I think the transpiler might be better for developing unique
front-end solutions in Pascal for the web, the WebAssembly compiler might
be better to bring existing large chunks of code to run on the web, with
minimal modifications, and for performance critical things.

But only time will tell. :)

Charlie
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Michael Van Canneyt


On Fri, 17 Mar 2017, Karoly Balogh (Charlie/SGR) wrote:

> Hi,
>
> On Fri, 17 Mar 2017, Michael Van Canneyt wrote:
>
>> In fact, there is an alternate approach, transpiling pascal to Javascript.
>>
>> It's much farther ahead than the webassembly target, already produces
>> programs running in the browser and the first web-based components are
>> already being developed using this approach.
>
> I believe these will be complimentary solutions in the end, one will be
> better for certain things than the other, with a lot of overlap, of
> course. I think the transpiler might be better for developing unique
> front-end solutions in Pascal for the web, the WebAssembly compiler might
> be better to bring existing large chunks of code to run on the web, with
> minimal modifications, and for performance critical things.

Fully agreed, and the "unique front-end solutions in Pascal for the web" is
the intended target.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Reimar Grabowski
In reply to this post by Graeme Geldenhuys-6
On Thu, 16 Mar 2017 11:14:17 +0000
Graeme Geldenhuys <[hidden email]> wrote:

> And I am pleasantly surprised! :)  That demo worked perfectly on my
> system. Sound, animation, graphics all silky smooth. Impressive indeed.

If running a 3 year old iOS Demo in a browser when we have seen Unreal Tournament 3 being playable there 4 years ago is impressive is debatable.
For me the impressive thing is that FireFox with WebAssembly manages to show the same performance as Chrome without it. Having them run side by side both fullscreen I can see no performance difference at all.
Perhaps the JS side is doing so little that it hardly matters (as it should be, when doing WebGL you want to do as much on the GPU as possible).
First benchmarks indicate that there isn't much of a performance increase with the current WebAssembly implementation over pure JS anyway.
The benefit is that you can 'run C code' in the browser and that's currently it.
Having a WebAssembly target for FPC would surely be nice (more options) but hardly a game changer currently.
In my little experience with WebGL the JS performance was never that big of a problem but getting lots of data into the browser without the transfer being super slow or the browser consuming alot more memory than it should.

R.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Graeme Geldenhuys-6
On 2017-03-17 14:57, Reimar Grabowski wrote:
> Perhaps the JS side is doing so little that it hardly matters (as it
> should be, when doing WebGL you want to do as much on the GPU as
> possible).

A very good point. It was probably all down to WebGL (ie: your GPU)
doing all the work.

Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Daniel Gaspary
In reply to this post by Michael Van Canneyt
On Fri, Mar 17, 2017 at 5:16 AM, Michael Van Canneyt
<[hidden email]> wrote:
> In fact, there is an alternate approach, transpiling pascal to Javascript.
>
> It's much farther ahead than the webassembly target, already produces
> programs running in the browser and the first web-based components are
> already being developed using this approach.

What is the role of those components ?

Reading this thread I was thinking would be nice (easier to work) ) to
have access to browser components via a fpc lib.

Something like fcl-browser-facilities (terrible name, I know), where
you could simple calls to DOM parts.

Whether this is already in fcl-js, sorry, I didn't knew about it..
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Michael Van Canneyt


On Fri, 17 Mar 2017, Daniel Gaspary wrote:

> On Fri, Mar 17, 2017 at 5:16 AM, Michael Van Canneyt
> <[hidden email]> wrote:
>> In fact, there is an alternate approach, transpiling pascal to Javascript.
>>
>> It's much farther ahead than the webassembly target, already produces
>> programs running in the browser and the first web-based components are
>> already being developed using this approach.
>
> What is the role of those components ?

You'll design a web app in the lazarus IDE (or Delphi IDE, for that matter).
The app will be compiled to Javascript.

Current thinking is that that there will be 2 "modes":
- "Free" Mode, where the CSS will determine the actual runtime look.
   The IDE will just create the DOM structure.
- "Exact" mode, where the app will look in the browser as it looks in the IDE.
   the necessary CSS will be generated for this.
In both modes of course the IDE and object inspector will be used to create
event handlers and whatnot in Pascal...

But this is all still under heavy development.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Michael Van Canneyt
In reply to this post by Daniel Gaspary


On Fri, 17 Mar 2017, Daniel Gaspary wrote:

> On Fri, Mar 17, 2017 at 5:16 AM, Michael Van Canneyt
> <[hidden email]> wrote:
>> In fact, there is an alternate approach, transpiling pascal to Javascript.
>>
>> It's much farther ahead than the webassembly target, already produces
>> programs running in the browser and the first web-based components are
>> already being developed using this approach.
>
> What is the role of those components ?
>
> Reading this thread I was thinking would be nice (easier to work) ) to
> have access to browser components via a fpc lib.
>
> Something like fcl-browser-facilities (terrible name, I know), where
> you could simple calls to DOM parts.

Forgot to say that there will of course be some classes to manipulate the
DOM at will.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Daniel Gaspary
On Fri, Mar 17, 2017 at 2:55 PM, Michael Van Canneyt
<[hidden email]> wrote:
> Forgot to say that there will of course be some classes to manipulate the
> DOM at will.


Thank you, Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Michael Schnell
In reply to this post by Michael Van Canneyt
On 17.03.2017 18:54, Michael Van Canneyt wrote:

>
> Current thinking is that that there will be 2 "modes":
> - "Free" Mode, where the CSS will determine the actual runtime look.
>   The IDE will just create the DOM structure.
> - "Exact" mode, where the app will look in the browser as it looks in
> the IDE.
>   the necessary CSS will be generated for this. In both modes of
> course the IDE and object inspector will be used to create
> event handlers and whatnot in Pascal...
>
Sounds Great !

Should be independent of compiling it to Java script or to Web Assembly
(provided decent "Widgets" are provided/usable with WebAssembly: I don't
know anything about those).

(Is this not more like an issue for the Lazarus community, as they are
supposed to provide "Widget Type" settings for such targets ? )

-Michael

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Michael Schnell
In reply to this post by Reimar Grabowski
On 17.03.2017 15:57, Reimar Grabowski wrote:
> First benchmarks indicate that there isn't much of a performance
> increase with the current WebAssembly implementation over pure JS anyway.

A "decent" Framework will compile both to machine code in an "ahead of
time" manner, so simple close loops should result in very similar
performance.

The compiler creating WebAssembly can introduce decent optimization. So
performance will depend on the Compiler-

Hand written Java Script might be good or bad so performance will depend
on the author.

It will be interesting to compare the result of the two fpc compilers,
when available :)

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

noreply
In reply to this post by Graeme Geldenhuys-6
On 2017-03-16 06:14, Graeme Geldenhuys wrote:

> On 2017-03-16 10:56, Graeme Geldenhuys wrote:
>> I’ll be pleasantly surprised if it works - after all, so many browser
>> features often only work for OSX and Windows, even though the browser
>> and web is supposed to be “cross-platform”.  I’ll report back later.
>> ;-)
>
>
> And I am pleasantly surprised! :)  That demo worked perfectly on my
> system. Sound, animation, graphics all silky smooth. Impressive indeed.
>

It did not work on my old Tecra 9 Windows 7 Laptop with about 3GB memory

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

noreply
In reply to this post by Reimar Grabowski
On 2017-03-17 09:57, Reimar Grabowski wrote:

> On Thu, 16 Mar 2017 11:14:17 +0000
> Graeme Geldenhuys <[hidden email]> wrote:
>
>> And I am pleasantly surprised! :)  That demo worked perfectly on my
>> system. Sound, animation, graphics all silky smooth. Impressive
>> indeed.
>
> If running a 3 year old iOS Demo in a browser when we have seen Unreal
> Tournament 3 being playable there 4 years ago is impressive is
> debatable.
> For me the impressive thing is that FireFox with WebAssembly manages
> to show the same performance as Chrome without it. Having them run
> side by side both fullscreen I can see no performance difference at
> all.
> Perhaps the JS side is doing so little that it hardly matters (as it
> should be, when doing WebGL you want to do as much on the GPU as
> possible).
> First benchmarks indicate that there isn't much of a performance
> increase with the current WebAssembly implementation over pure JS
> anyway.
> The benefit is that you can 'run C code' in the browser and that's
> currently it.
> Having a WebAssembly target for FPC would surely be nice (more
> options) but hardly a game changer currently.
> In my little experience with WebGL the JS performance was never that
> big of a problem but getting lots of data into the browser without the
> transfer being super slow or the browser consuming alot more memory
> than it should.
>

Why run webgl through javascript if you could just make something like a
flash plugin object (like youtube videos) that plays opengl scenes using
some native format similar to how flash uses SWF files, or whatever?

I think there was some opengl plugin object, but can't remember...

It seems like almost the web browser is trying to become Emacs,
everything and the kitchen sink, though...

If it includes opengl or webgl, and video players, and.. everything
under the sun.. it makes me wonder whether we should really not be going
back to exe's again... I.e. if you want to download a opengl
application, you just download an exe/elf program instead of running it
in the web browser ;-)

Still, web browser (abuse syndrome) apps are cool.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: WebAssembly Target

Free Pascal - General mailing list

Am 12.04.2017 16:10 schrieb <[hidden email]>:
> Why run webgl through javascript if you could just make something like a flash plugin object (like youtube videos) that plays opengl scenes using some native format similar to how flash uses SWF files, or whatever?

Because the point is not to need some strange, obscure plugin that works only on a subset of the platforms the browser supports when the script engine of the browser is powerful enough to do it itself.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Bls: WebAssembly Target

Free Pascal - General mailing list
In reply to this post by Michael Van Canneyt




Pada Sabtu, 18 Maret 2017 0:54, Michael Van Canneyt <[hidden email]> menulis:

You'll design a web app in the lazarus IDE (or Delphi IDE, for that matter).
The app will be compiled to Javascript.

Current thinking is that that there will be 2 "modes":
- "Free" Mode, where the CSS will determine the actual runtime look.
  The IDE will just create the DOM structure.
- "Exact" mode, where the app will look in the browser as it looks in the IDE.
  the necessary CSS will be generated for this.

In both modes of course the IDE and object inspector will be used to create
event handlers and whatnot in Pascal…

But this is all still under heavy development.


Seriously? Where can we try or test this? This is really a great news! It reminds me of Morfik. :)

Hope the development will continue.

Regards,


–Mr Bee



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
1234