Native Web Gaming, Native Code and Mozilla?
ya knygar
As i see from the initiatives - the Mozilla is interested in advanced
gaming experiences in the Web, that leads me to writing this post,
please, don't shoot the messenger.
---
Since the [ http://blogs.adobe.com/flashplatform/2011/09/announcing-flash-player-11-and-air-3.html
]
"The Next-Generation Console Has Arrived" with some API's that enable
the competition with Mozilla's WebGL
it has been promoted by
http://www.joystiq.com/2011/10/04/epic-and-adobe-announce-unreal-engine-3-support-for-flash-11/
[ http://www.youtube.com/watch?v=UQiUP2Hd60Y ]
that, however strangely, (as i understand) is -- C/C++ that may actually relate
to the http://labs.adobe.com/technologies/alchemy/
..and there are "next-generation of the Alchemy technology will be coming soon"
don't know what it would be, actually, but i think it would be close to the
http://blog.chromium.org/2011/08/native-client-brings-sandboxed-native.html
that also being integrated into Google Chrome, currently enabled for
the Google App Store and needs to be enabled manually for other cases,
as i understand.
The latter message from Chromium team "ensure that all Native Client
apps are updated to PNaCl when it’s ready – and in the meantime avoid
the spread of instruction set architecture dependent apps on the web."
That, as i see it, gives the Google Chrome - 2 serious gaming
platforms with near to native performance (as i think -- approximately
5-10% loss in NaCL and near 2x loss in that ubiquitous Unreal Engine,
for Flash) when the WebGL, given the JS performance -- would be around
4x loss comparing to the today's 'native' gaming. All these are a
rough estimations and i'll be glad if you'd point that i'm generally
wrong, also i would be glad if WebCL would add the points to the
current Mozilla planned platform, as i see that platform from the
Mozilla's employees comments.
But, i see the !3 (including WebGL) real gaming platforms in the
Google Chrome currently, given the Google Dart performance orientation
-- maybe 4.
I am really worried if Mozilla's 1 current JS/HTML/CSS platform could
compete with these other, built-into the competing browser(s) in the
near future, let's say - in 2 years.
I adore the Mozilla's view and work, i am amazed with how WebGL and JS
evolves in communities and i like JS and it all seems cool enough for
'3D Web' to, finally, appear.
Anyway i, personally, don't think that it would be enough to compete
with that Chrome offers in the gaming field and gaming field i think
is what constantly driving the innovation and would further actively
drive the Web with Augmented reality etc.
Given the Flash history and it's market share that IMO could only rise
with that new accelerated or 'native code' platforms, also the PNaCL
and Dart -- i'm not talking about some 'pure' Web scripting platform
that looks like that 'HTML5' languages trio as for Mozilla but i ask
about platform that not necessarily is for the semantic, parsing
goods.. still appear on the real Web or should i call it Internet.
I'm talking - about these "little black boxes" that has evolved as a
pre-compiled programs on all the major platforms and now being
transferred in a different ways of Web-ified native apps to the actual
Web.
Ignoring it or going against it under the 'pure-Web' campaign isn't a
wise or even completely honest decision, i think.
Given that WebGL/CL with their frameworks are likely to evolve into
something even less 'Semantic Web' that the Web is now -- and you
support WebGL -- and, anyway, encourage the building of Web Apps that
are closed enough to try the 'parsing' besides the provided(by the Web
Apps developers) API's
-- i came to conclusions --
- The pragmatic and useful future of the Semantic Web Apps Web is in
providing the API's on higher - in the JS build representation layer
or even much lower - in the Databases level, not in the HTML/CSS part,
arguable, but that is my conclusion.
- The pragmatic and useful future of the Searching/Aggregating in
these Web Apps Web is in the Pushing not Crawling.
- The good points for the Open Web Industry ('near-IT something',
Mozilla included) is not in the aggressive pushing of no-DRM-able
HTML5 platform along with 'Open Source' by the client's nature -
JavaScript, but in the increasing promotion of the Open Source
licensing (like in org's definition) itself and promoting the Open
view on the content distribution.
By this -- adding some kind of the digital signatures for apps and,
maybe, pushing forward the Moz Open Web Apps Store initiative -- i
think, we could try to avoid "black boxing" of the Web.
For the third thesis i came to the personal conclusion -- the Web as
defined by looking through the web browser or by HTTP is not the only
possible definition now,
the other possible is - the Web that being built on the Apps (that
sites, portals, everything in the environment) that could connect in
one or another way with each other and could be interacted with the
web browser like Firefox or with another type of user agent, like B2G,
Chromeless, etc. that, respectfully, isn't the browsers but more like
execution environments.
In such a situation which i think is the - nowadays paradigm - for one
recent example of the Google Dart launch i'v seen many comments about
- why not to built the Web execution environment for the as many
languages of people's choice rather than.. other way of One Stack To
Rule Them All that Mozilla along with other is approaching.. from the
comments of Mozilla's HQ - it looks like (looks! not the actual state,
i hope) Mozilla is approaching that way exclusively and Google as a
competitor - inclusively, that looks much wiser and actually -
productive.
To sum my personal conclusion - i think - providing the people with
these choices like Chrome team do now is more important for the people
themselves than to provide the !1 choice that !looks like a good way
to secure the future of the Web from closeness.
---
My questions to the Mozillians from Mozilla Corp, Foundation and
related elsewhere are:
1. Who think that compiled into some sort of 'closed' binaries - code,
like we now have on the majority of the computing platforms, is a
NO-WAY for the Mozilla's Open Web principals and why?
2. What stops the Mozilla Firefox team currently for including
something like open source NaCL plug-in into the roundups, like Google
Chrome team did?
3. How do you see the B2G future in this context, particularly
comparing to that Chrome OS that would likely to use NaCL by that - if
some day ported to the smartphones - would provide these native game
experience? To be strict - will the B2G in that case be the
performance respecting gaming platform, without something like C apps
to provide the best speed?
4. How do you see the competition for Openness by Mozilla with these
two other major platforms - one of which is Apple's platform with
particular absence of the ideological separation between Web links,
Offline Web Apps or not so Web or not so Apps, still Networking and
generating Web-alike content on your devices and second of which is
Google platform with the same anarchism in mind.
Please help me to understand this situation further.
--
PS: all this is my personal conclusion and may not be up-to-date with
the real state or in other ways correct, please, don't take it too
personally and correct me, if so.
Benoit Jacob
dev-platform list, rather than this one.
2011/10/13 ya knygar <kny...@gmail.com>:
> That, as i see it, gives the Google Chrome - 2 serious gaming
> platforms with near to native performance (as i think -- approximately
> 5-10% loss in NaCL and near 2x loss in that ubiquitous Unreal Engine,
> for Flash) when the WebGL, given the JS performance -- would be around
> 4x loss comparing to the today's 'native' gaming.
I think your implicit assumption here is that games are bound on
computational performance, and while that's probably true for certain
kinds of games, there's a lot of games that are rather bound on
graphics performance and for them, WebGL+JS allows to get pretty close
to "native" speed.
For what is actually bound on computational performance and actually
useful for web pages/games (like, physics artificial intelligence),
there are several approaches left to explore before one could declare
that JS has to be replaced:
* RiverTrail
* WebCL
* JS compiler improvements
* JS language extensions (more typing etc)
Benoit
Henri Sivonen
> to the http://labs.adobe.com/technologies/alchemy/
> ..and there are "next-generation of the Alchemy technology will be coming soon"
There is a similar project that allows C/C++ code to be compiled to JS:
http://emscripten.org/
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
ya knygar
(from wiki)
"River Trail is an open source engine, developed by Intel, for
interpreting JavaScript code using parallel computing when the
microprocessor allows it. " cool, how is that relates to the Khronos
WebCL implementations?
> First of all i think this thread would be more on-topic on the
> dev-platform list, rather than this one.
i'v tried hardly to guess for this, even looked at the lists list
again trying to find the best place :) well.. since you have still --
replied to the planning .. let it be here? I'v really considered the
'dev-platform' as a second variant but my logic was (from the latest
messages there) -- 'platform' is for the internal platform discussion
(XUL the lists list say) .. and 'planning' is for .. suggestions on
planning.
> I think your implicit assumption here is that games are bound on
> computational performance
yes,
i'v written that for "serious gaming platforms" i think i have misused
the term a bit.. that games could be called hardcore as opposite to
the casual [ https://en.wikipedia.org/wiki/Casual_game ] gaming though
i don't like these terms. I don't like the separation of 'gaming'
based on some quality of the representation, either. As i'v said I am
glad with the current WebGL evolution and i well see the new age for
these Casual and (oh..) Indie game developers that previously was
stuck with the Flash (with all it's nuances) or old in-browser JS
(with all it's).
That is a great leap forward and i see the great examples of that kind
of accelerated JS Web evolution right now. I'v seen a lot of kind
comments about - how glad it would be to finally abandon 'that'
add-on's and move with the 'HTML5' stack, thanks to the WebGL
initiative.
Also i see the comments like there -
http://www.joystiq.com/2011/10/06/hold-on-ue3-crytek-is-investigating-flash-for-cryengine-cr/
almost for any related to the 'native performance' post. Java's Quake
Live was one well proven example and now It's going to real trend.
As i know from personal experience - gamers at large - couldn't care
less about languages in which the game was written, rare examples of
Python or other 'modding' (scripting) are rare. Generally living the
'main line' gamers with the (some times) provided - native SDK's.
When gamers come to the Web they had come to the Flash gaming, later
to some 3D Java gaming now they would come to the 3D Flash Chrome
gaming (Chrome in general - works better with Flash plug-in, isn't it?
All people i'v seen - playing 'mission critical' Flash games - have
played in Chrome -- due to it's lite-weight stability charm). Later it
could be 3D NaCL gaming (many aren't in fond of Flash stability, you
know). I think - you also know that besides all the nuances -- the 3D
generally, increasingly rules in gaming, even for the most casual,
arty, indie whatever. I'v seen the WebCL working demo's -- pretty
cool. But i'v seen the RO.ME as a reference example of WebGL
capabilities and it isn't really cool. I'v seen many 'heavy' WebGL
demos, frameworks.. still it doesn't impress even near as that
Youtube's UE3 Flash demo. Practically i see the situation with the
current Mozilla stack as --- Moz gaming stack is kind of Wii against
the Google's coming PS3/XBOX :)
First started earlier, allows 'casual' games with some cool
interactions -- that is Firefox
Second is fully-blown maybe even overblown at the time of the release,
having not so many but important titles at the start -- in this case -
Angry Birds (it's ads is in Chrome itself BTW, you could see in the
App Store icon on a blank page, and i'v seen it on the first lines of
Google App Store).
Second - finally - has all the casual benefits like cool interfaces
along with all the heavy-lifting performance that is needed to run
UE3, CryEngine, whatever else is needed to be considered as a platform
for any type/kind of gaming in result - it wins even in parts where in
reality it has not overwhelming strengthens or even has loses.
First is cool for 3D Web, 3D Ads, DOM manipulations.. finally for the
old school surfing but not gaming.
Am understood-able in this explanation?
I truly don't want the next round of closed source plug-ins for the
gaming like it is going forward now.
i could argue that the biggest strength for most of Windows users i
have met recently - is gaming.
i could argue that the real - defining the choice - strength for most
of Google Chrome users i have met recently - is gaming.
For one example - as i'v seen on recent statistic i could trust, actually
- Linux has 1 percent of desktop users, worldwide, Windows has 92.
In all other the Linux could fit very well, still - no growth over
that 1 percent..
[ from the http://blogs.adobe.com/open/2011/06/focusing-on-the-next-linux-client.html
]
another reason why Adobe abandoning Linux desktop platform, another
reason why MS has so big emphasis on gaming currently and it had
always, in my opinion.
Another reason to make the open, standardized 'native' apps (gaming
platform) for the web.
> there are several approaches left to explore before one could declare
> that JS has to be replaced:
i think so, i don't want the JS to be replaced as like with competing
Dart, but i do want the Dart as a second variant for the C or Java
lovers, why not?
Most of my wonders not about the Dart as a possible 4th platform and
even not about 3rd - JS (WebGL)..these i think would help themselves.
but about the first two -- Flash and NaCL, that potentially going to
execute ANY modern language in the Browser!
My wonders are about Mozilla that has publicly stated the absence of
interest in Native Code some time ago (however Mozilla stated
something comparable about OS's and now there is B2G ;)
As i'v said not a once i love Mozilla's view.. maybe the correctly
would - i like the Mozilla's manifest and Open Web. And i really like
JS and what has it done, since it the Web becoming more and more
interesting, honestly. But that not excludes the Native Code in
browser and i'v tried to explain it in the first message.
-
There are nice post on the topic
http://chadaustin.me/2011/01/in-defense-of-language-democracy/
in the first comment "Why does everyone insist on converting Browsers
into a network based OS?"
that was January. That man doesn't want to converting the Browsers into the OS,
but as i see - W3C along with Mozilla's B2G experiment/WebAPI's along
with Chrome OS product (with NaCL) - are For it,
and the OS with one 'real' language, isn't really a modern and
user-respecting OS, as for me.
As i'v said -- Apple seams like for the ubiquitously good experience
and well controlled, well profitable market in their products so they
are also for Native Code..well.. ObjC code that with some approven
WebKit leaning acts like a stand-alone Web App.
On Thu, Oct 13, 201I think your implicit assumption here is that games
are bound on
computational performance1 at 4:32 PM, Benoit Jacob
ya knygar
bytecode instead of executing it in some trusted environment like
PNaCL could potentially do..
folks on the Dart comments - suggesting the http://parrot.org/ to heal
the Web from One Rule syndrome, eventually, i kind of asking about the
current state of it in Mozilla and Mozilla's plans.
For converting the one high level lang to another there was
https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/253122f392e1f4a8#
the man converted "the 5-line 'Hello Dart' example
into a 225K-line Javascript program totalling 9.2 Mbytes. "
than, using the '--optimize' it appeared as
"9.2Mbytes to 0.19Mbytes,
and from 225K lines down to 14600 statements.
But the number of included functions is still high at 2645."
it is all work in progress etc. but i think the whole conception of
automatic translation from one language to another
with all that usual auto-generated bloat it isn't a right way to make
the programming work for people.
The right tool for the job conception is cool and it, actually gives
another point for using the C/C++ as the fastest
and the widely used with many good existing toolchains like that UE3
that could be re-used for building the 'heavy' gaming on the web.
azakai
nor NaCl will run on an iPad for example, nor are they open standards.
That is the main difference I think between them and the web.
Aside from that, I am not sure the performance comparison is that bad.
Flash is not particularly performant in general, we will need to see
more benchmarks on that, and PNaCl's performance is not yet known,
since PNaCl is still a work in progress (if/when the portability
issues are sorted out, performance may suffer there).
JS on the other hand is quite fast now and getting faster still.
Graphics performance likewise. The main issue now with running entire
games on the web is, in my opinion, problems with running large
compiled JS files. Once that is resolved, you should be able to run
standard game engines on the web with very good performance. And those
game engines will then run everywhere the web runs (unlike Flash or
NaCl).
- azakai
On Oct 13, 8:55 am, ya knygar <kny...@gmail.com> wrote:
> Hello!
>
> As i see from the initiatives - the Mozilla is interested in advanced
> gaming experiences in the Web, that leads me to writing this post,
> please, don't shoot the messenger.
> ---
>
> Since the [http://blogs.adobe.com/flashplatform/2011/09/announcing-flash-player-...
> ]
> "The Next-Generation Console Has Arrived" with some API's that enable
> the competition with Mozilla's WebGL
>
> it has been promoted byhttp://www.joystiq.com/2011/10/04/epic-and-adobe-announce-unreal-engi...
> [http://www.youtube.com/watch?v=UQiUP2Hd60Y]
>
> that, however strangely, (as i understand) is -- C/C++ that may actually relate
>
> to thehttp://labs.adobe.com/technologies/alchemy/
> ..and there are "next-generation of the Alchemy technology will be coming soon"
>
> don't know what it would be, actually, but i think it would be close to thehttp://blog.chromium.org/2011/08/native-client-brings-sandboxed-nativ...
Jeff Gilbert
To my knowledge, I would peg the more relevant concerns as lack of support for mouse-lock or gamepads, initial uncertainty about capability penetration, instability of availability of websockets, and lack of UDP networking support. I also believe that most of these are currently being presently addressed or investigated.
Furthermore, responsibility for supporting the plethora of graphics devices and drivers basically becomes the web browser's. You really get a write once, run everywhere situation.
-Jeff
- azakai
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning
Robert Kaiser
> But, i see the !3 (including WebGL) real gaming platforms in the
> Google Chrome currently, given the Google Dart performance orientation
> -- maybe 4.
Can you show us the Open Web Standards for those technologies, i.e.
those developed by a consortium of vendors in the open?
If not, I fear they don't fit with the very principles Mozilla is built
on and therefore are probably not an option, even for the general public.
While gamers might not care who they hand their piles of money to, we
care that everyone can play by the same rules to be creative and
innovative and put up their work, and that requires (among other things)
open, cross-vendor standard efforts.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
ya knygar
> The web runs everywhere, whereas Flash and NaCl do not.
nor do Java, but it doesn't prevent the developers and users from
using it because it fits their needs and there isn't (or wasn't before
WebGL) better variants if you want the considerably fast 3D to be ran
from as many browser windows (and 'other' platforms as well) as
possible. The demand is clearly here, for the long time, isn't it?
> The web runs everywhere
One of the points for something like PNaCL is to ensure that web runs
everywhere the same. Currently if you are Web Programmer and want to
use some cool enough standardized tech you see the compatibility like
http://caniuse.com/#search=webgl (this is due to the driver that you
need to update, partially.)
or http://caniuse.com/#feat=transforms3d
for every other browser you see different bits of CSS, HTML etc.
supported, from time to time.. Web isn't really constant when it comes
to big multi-platform web apps, the only plus is that there are UA
that you could look-up and you could spend the time - tweaking the
code for every other web browser to work the same. The usually
difference isn't very significant (except for the IE support) but it
is there.
For one current example - for JS - It's said that different compilers,
especially JIT, i think - run differently,
as you could see -- many WebGL products, not even demos - being
stretched to one or another browser.. yes, that hurts the One Web
conception, that hurts the Mozilla that seems like the main prophet of
this.
So - one another point for standardizing and developing PNaCL or
whatever it would be called VM is for the real, significant
advancement on interoperability. So that would help the One Web, even
if it wouldn't work with HTML/CSS.
Of-course - HTML/JS/CSS would be used but you need to use the right
tool for the job, for example - some people like Python, and they try
through some http://pyjs.org/ and etc. just to get the Web to show
what they like to show, but is it cool that for every next lang you'll
be tricking with such a tools, just because the Web is used to JS
exclusively (and actually i don't think so -- as there, at least was -
the significant share of JVM plug-ins, Flash? even ActiveX being used
somewhere.
Now there are - additionally - Silverlight and .NET that could be like
that -- on the 92% of desktop users PC's .. enough to form some part
of the Web, isn't it.. these are another popular DRM-able platforms
along with Flash that exist merely because of the PNaCL absence as an
open standard, i may say.
More correctly - because Google has enough to do and Mozilla without
has enough to do, all in their own way, it seems.. W3C has nothing to
do except give recommendations that one company could follow another
couldn't care less. The real indicator is real market and in this
situation it indicates, really, you would see the Flash next year if
you don't want to see now.
The HTML5 'stack' agreement is cute but isn't helping as you see - the
plug-ins are here, even more plug-ins, and old one's with 60-70-80% of
market share that you could easily name the de-facto Web standard,
though - not open, again, because there some people in Mozilla still
thinking that it isn't needed or a priority, that is what i think. It
isn't about the money or workers Mozilla Corp need, i hope.
I think - Mozilla with Google has enough power to push any nice
standard and Apple won't resist more than it resisting WebGL on iOS
now. Rough but honest estimation.
> Neither Flash
> nor NaCl will run on an iPad for example, nor are they open standards.
Flash is not but Google is really smart enough to not prevent and
actually help on further standardizing of NaCL or kind, i hope. They
are pushing the open WebRTC that, as for me, is even more
'revolutionary' that PNaCL in the terms of business changing.
Again - the demand is here, translating the everything into JS isn't
cool, people say it brakes on every real average app, if not brakes -
generates the bad, low performance code. I haven't tried myself but i
think it is even worth than the code which that these WYSIWYG creators
was creating some time ago, i think you know what results i'm talking
about.
@Robert Kaiser
> Can you show us the Open Web Standards for those technologies, i.e. those developed by a consortium of vendors in the open?
Sadly - no, but since the LLVM, NaCL and PNaCL whenever they are - are
open source and since it is Google's interest to standardize these --
the standardization need to come by Mozilla's acceptance and
collaboration.
The situation was ok back to then, but now with this next wave coming,
i can say - you'll need to decide faster.
> If not, I fear they don't fit with the very principles Mozilla is built on and therefore are probably not an option, even for the general public.
Well, Google Chrome team(as with SPDY that eventually may act for all
the Store and Engine apps if it isn't actually - giving the advantage
etc.. so what?) thinks differently and that would be some many
millions of Web users that have the NaCL from the Store and may not
even realize or care - standard it is or feature or what. Adoption may
change really fast so it even isn't about the numbers of users of
purism of the Web. There would be always the fight, but, as i'v said
already - the Chrome has it all now and Firefox - not or not even
plans.
> While gamers might not care who they hand their piles of money to, we care that everyone can play by the same rules to be creative and innovative and put up their work, and that requires (among other things) open, cross-vendor standard efforts.
Sure! that is why people i know and myself - respect and usually use
Mozilla's software, however - if i need the Chrome to run some cool
game, what would prevent me from using the Chromium and used once, i
could switch eventually - that is where Mozilla fails now, from what
i'v seen.
To add -- the NaCL standardization work may differ much from that
Khronos/IETF/W3C that you might have in mind by what is needed -- this
work is far more related to software development, i think, so you may
never see the initiative from these SDO's, on other side - Google
Chrome team might not care about these like they might not care on
Mozilla's view on the Web, so that is up to you - to catch the
situation, not them - to send the better invitation.
For one example - Dart that Google would propose to the Mozilla, or it
has proposed at the moment, by the announcement..
You don't like it? so what.. it wouldn't stop the Chrome team to
implement it and build the faster apps under the Google brand that
Mozilla, even with some extension wouldn't catch because you'll need
to integrate it 'in the guts'. Google could provide the constructor
like they did for that (damned as for me) Java language and Android,
that is the dream of many and eventually people would jump on Dart
train like this. Another example that PPAPI, they have used Netscape
(they may say - yours) work and now they have done something more
efficient, you won't catch it, Opera wouldn't? so what, they will use
it, it would be fast and they would eventually win like they are
wining now with gaming. Even more - if PPAPI is stopping the PNaCL
adoption -- the Google say "the goals of the project are to provide a
framework for making plugins fully cross-platform" that is even cooler
from the side view, so what is wrong with Mozilla, people would ask..
and Mozilla is in situation where you'll have to introduce better or
obey to what they have, isn't it?
So i ask all you, Mozillians, and you especially - Robert Kaiser as a
B2G developer, to think again on the situation, not from the position
of - "well, nice, give us actually the thing and we'll see then", but
from the position of really existing Competitor that has the mobiles
that Mozilla is only about to catch up, that has the browser that
grows faster than Mozilla's and Search that almost means the Web for
many users - that Mozilla, probably won't ever catch up to make Open
Source, Free, Open Web or whatever you are personally for, in Mozilla.
That is the main competitor, other big - IE - has own 'native
performance' plug-ins and HTML5 for GUI's, if you wish, about other -
i don't even care to elaborate now, in the end you know it all, i
guess, why bother.
Wes Garland
> One of the points for something like PNaCL is to ensure that web runs
> everywhere the same.
That is never going to be true. A skinny little ARM X terminal and a full
quad-core X86_64 gaming rig will never work the same, unless you cripple the
hell out of the gaming rig.
> Currently if you are Web Programmer and want to
> use some cool enough standardized tech you see the compatibility like
> http://caniuse.com/#search=webgl (this is due to the driver that you
> need to update, partially.)
> or http://caniuse.com/#feat=transforms3d
>
How does PNaCL solve OpenGL driver bugs?
> For one current example - for JS - It's said that different compilers,
> especially JIT, i think - run differently,
>
IMHO, if you make all the compilers run the same, then you will stall
innovation in the long term.
Notice how well the web matured when there was one only one browser in
common use (IE6).
Notice how much JavaScript compilers improved when everybody got into an
arms race a few years ago.
Homogeneity? Do Not Want. The Web needs evolutionary pressure from multiple,
competing vendors.
> So - one another point for standardizing and developing PNaCL or
> whatever it would be called VM is for the real, significant
> advancement on interoperability. So that would help the One Web, even
> if it wouldn't work with HTML/CSS.
>
They already invented that, they're called Java Applets.
> W3C has nothing to
> do except give recommendations that one company could follow another
> couldn't care less.
WOW, I can tell you've never tried to draft a standard.
> I think - Mozilla with Google has enough power to push any nice
> standard and Apple won't resist more than it resisting WebGL on iOS
> now. Rough but honest estimation.
>
Right, just like they buckled and added Flash support?
> Again - the demand is here, translating the everything into JS isn't
> cool, people say it brakes on every real average app, if not brakes -
> generates the bad, low performance code. I haven't tried myself
I knew before you said "I haven't tried myself" that that was true. I
haven't tried writing any games in JS, either, but I *do* write an awful lot
of JS code, on a wide variety platforms. It is almost never my bottleneck;
my issues are always DOM rendering time, I/O bandwidth, stuff like that.
I have no problem believing statements made by folks like Jeff Gilbert who
say that the real bottleneck is shoving data at the GPU for good gaming.
Improving the speed of generation of the data by 10% isn't going to help if
shoving it at the GPU takes 99% of the task time.
There is no magic bullet.
Oh, and by the way: Developers, developers, developers, developers!
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Robert Kaiser
>> Can you show us the Open Web Standards for those technologies, i.e. those developed by a consortium of vendors in the open?
>
> Sadly - no
Exactly. And open source has nothing to do directly with open
cross-vendor standards, so not a real argument here.
> The situation was ok back to then, but now with this next wave coming,
> i can say - you'll need to decide faster.
WebGL is a technology that is just as new as those others you point to
(it's just a slight bit less hypothetical as it's already in existence
and standardized), and every new technology needs some time until it's
adopted to a point where it can show its power.
> Well, Google Chrome team(as with SPDY that eventually may act for all
> the Store and Engine apps if it isn't actually - giving the advantage
> etc.. so what?) thinks differently
Right, they think about profit for their shareholders while we think
about profit for people on the web at large.
Single-minded single-for-profit-vendor technologies will never
ultimately be profitable for the wide masses but for that one single vendor.
Chrome supports h.264, do you say we need as well? Actually, Mozilla
said "no" to that and rooted for a web video format that can be used and
produced by anybody, and ultimately even Google bowed to that.
We fight for the user. Mozilla is the Tron of the Internet. (Sorry for
the analogy, but I just viewed both Tron movies yesterday *g*)
> You don't like it?
It's not about "what we like", it's what is best for the future of the
Open Web.
> So i ask all you, Mozillians, and you especially - Robert Kaiser as a
> B2G developer [...]
Haha, you obviously easily fall for thinking you know something without
having done some investigation. Hint: I'm not even really a developer.
(And I'll keep my statements here short and precise, I'll leave overly
long and redundant to you - though I'd prefer if you'd try to go more
for the "keep it short simple" route.)
ya knygar
> That is never going to be true. A skinny little ARM X terminal and a full quad-core X86_64 gaming rig will never work the same, unless you cripple the hell out of the gaming rig.
> That is never going to be true.
i'm not pretending the exact result, i see the tendention that these
successful Web forming corporations follow currently and i describe
my, based on experience from gamers discussions - opinion.
> A skinny little ARM X terminal and a full quad-core X86_64 gaming rig will never work the same, unless you cripple the hell out of the gaming rig.
the difference with codename: 'PNaCL' would be in fairly similar
performance on fairly similar rigs.
> How does PNaCL solve OpenGL driver bugs?
dunno, what i'v meant there is - you, as a developer would have the
non-consistent experience with while you'll try to make 3D for the Web
- anyway, so it is - currently - isn't much better than, for example -
Java - that ensures that "Write Once.." though in another, also - not
a perfect - way.
> They already invented that, they're called Java Applets.
the difference with codename: 'PNaCL' would be in providing the !many
languages, that is obviously more interesting than one, also - Oracle
isn't Google, obviously. That fact that Sun aimed to the good thing
that PNaCL proposes but had failed, just proves that PNaCL or other
multi-lang variant had a good chance to finally make it - given all
the benefits. Just as easy.
> W3C has nothing to
> do except give recommendations that one company could follow another
> couldn't care less.
> WOW, I can tell you've never tried to draft a standard.
i'v read the standards, for example - the W3C and WHATWG view, and i
definitely have seen different degree and even implementations, some
times in IE, some times there are others that ignore or otherwise
propose with these prefixes or other 'temporary' staff that often gets
to production if you don't want to chase the never-coming perfection
of love and agreement between main browsers. Em.. and i try to watch
the domains in emails of standards authors, if that proves something
:)
So - i can't understand what you are talking about in that statement?
Maybe i need to copy-past here "couldn't care less." examples?
Maybe i was wrong and right would be - they do care but in result they
do prefix, that people tend to use?
> Right, just like they buckled and added Flash support?
For now the mountain comes to --
arstechnica.com/apple/news/2011/06/adobe-updates-flash-builder-and-flex-to-target-iphone-ipad.ars
what that proves? My personal opinion is that Apple would go against
everything that could potentially sell books or other content not in
their market. That changes nothing, iOS has no Mobile Firefox and
possible would never has, so why Mozilla should care? OSX's likely to
have Flash like they have now, they could have 'PNaCL' as well,
preinstalled in Firefox just like it would be in Chrome.
> I have no problem believing statements made by folks like Jeff Gilbert who say that the real bottleneck is shoving data at the GPU for good gaming. Improving the speed of generation of the data by 10% isn't going to help if shoving it at the GPU takes 99% of the task time.
And i have a problem - in that problem i believe - i would see what
i'm seeing now in that UE3 video soon in Flash, and i wouldn't see it
any time soon in canvas. Just as easy. I won't battle the Mozilla's
minds, in case of denial - we all could meet in a year and discuss if
Flash 11+ became a better gaming platform than 'HTML5'.
> There is no magic bullet.
maybe even nothing magic, just the support of existing AAA class SDK's
for Flash and 'HTML5' would rather be seen as a toolchain for a faster
sites, not gaming.
@Robert Kaiser
> Exactly. And open source has nothing to do directly with open cross-vendor standards, so not a real argument here.
in a case of WebRTC it had, pretty much directly.
> WebGL is a technology that is just as new as those others you point to (it's just a slight bit less hypothetical as it's already in existence and standardized), and every new technology needs some time until it's adopted to a point where it can show its power.
sure, but what prevents from the let's use Python, Lua, C, whatever we
like? I can't understand what would be proven with JS in current case
-- i can't imagine that people day to day using JS would be just
happy, i can imagine - they would be sad just because the variety is
good. As we kind of realize - translating languages doesn't give a
nice result and i think it would be like Pyjamas now, see that view -
http://pyjs.org/will_and_abe_guide_to_pyjamas.html
> Right, they think about profit for their shareholders while we think about profit for people on the web at large.
> Single-minded single-for-profit-vendor technologies will never ultimately be profitable for the wide masses but for that one > single vendor.
That is goood, but
the result you'll see would likely be - they would lead they way, you
would lead yours, you are giving them the precedent by ignoring the
superior tech, isn't it clear even now?
> Chrome supports h.264, do you say we need as well? Actually, Mozilla said "no" to that and rooted for a web video format that can be used and produced by anybody, and ultimately even Google bowed to that.
i know, that is a considerable success,
another example is https://en.wikipedia.org/wiki/O3D
they show that they go ok with superior variants that 'you propose'!
> We fight for the user. Mozilla is the Tron of the Internet. (Sorry for the analogy, but I just viewed both Tron movies yesterday *g*)
i had not a bit of doubt.
So try to battle for and have fun with Quorra and kinds even if it
isn't the standard now and, even, if she is in some others camp and
even if it isn't the Webby web, since it is reality anyway.
> It's not about "what we like", it's what is best for the future of the Open Web.
that is exactly the point to adopt, liberate if you wish - as much as
possible not only that you see as a good future.
The progress is in variety the best progress is in ubiquitous and Open
variety, which you are denying, in this case - by your own, Mozilla's
cost as the two serious enough competitors has gone with the faster,
easier for newcomers like desktop gamemakers and, even, proven by
previous attempt - Java - tech.
> Haha, you obviously easily fall for thinking you know something without having done some investigation. Hint: I'm not even really a developer.
while you answer very similar to the developing developer that
matters, you are - obviously from that - look like a developer :)
I'v honestly thought that you are one of the greatest developers on
most of Mozilla's tech as i'v seen your comments and answers as from
Mozilla team - everywhere.. no, really.
I am not easily failing somewhere, i'v see the list of devs on Wiki
and Github before posting this but, i assumed that you are a manager
or some chief that anyway relates to B2G as you have answers and other
posts there.
for other example the B2G isn't even in Mozilla repository, that
should mean that it isn't Mozilla's Mainland project?
> (And I'll keep my statements here short and precise, I'll leave overly long and redundant to you - though I'd prefer if you'd try to go more for the "keep it short simple" route.)
thank you, i have tried to explain shorter but i rather fail with it,
so - thank you for listening to me as i am, i really appreciate.
Boris Zbarsky
>> They already invented that, they're called Java Applets.
>
> the difference with codename: 'PNaCL' would be in providing the !many
> languages
So do Java applets. To run one, you need to have some Java _bytecode_,
not Java _source_.
So any language you can compile to Java bytecode (e.g. anything in the
list at http://en.wikipedia.org/wiki/List_of_JVM_languages ) can be run
in an applet.
> That fact that Sun aimed to the good thing
> that PNaCL proposes but had failed, just proves that PNaCL or other
> multi-lang variant had a good chance to finally make it
So because someone tried to do something really hard that people didn't
really want all _that_ much and failed means that someone else will
succeed at it?
I'm not sure I follow the logic, honestly.
-Boris
Joshua Cranmer
> @Wes Garland
>
>> They already invented that, they're called Java Applets.
> the difference with codename: 'PNaCL' would be in providing the !many
> languages, that is obviously more interesting than one, also - Oracle
> isn't Google, obviously. That fact that Sun aimed to the good thing
> that PNaCL proposes but had failed, just proves that PNaCL or other
> multi-lang variant had a good chance to finally make it - given all
> the benefits. Just as easy.
The JVM was explicitly designed with the goal of being cross-platform,
and it has become a well-targeted platform for language development, as
well as a well-researched one. As far as I know, the JVM is capable of
equaling or exceeding native performance in code, except at native
interface barriers. It also has the tremendous advantage of pretty much
universally working right now in every major browser on most platforms
(except those which forbid the JVM at all, snark snark).
By contrast, PNaCl is targeting a relatively new architecture, and an
architecture for which these kinds of cross-platform abilities is not an
explicit design goal. For an explicit discussion of this, see the "LLVM
IR is a compiler IR" thread in llvm-dev mailing list, started on October
4 of this year.
There might be room for a better language on the web than JS. PNaCl is
not that language.
Robert Kaiser
> sure, but what prevents from the let's use Python, Lua, C, whatever we
> like?
Probably nothing, they probably all can be translated into JS and
executed from there on the web platform in some way, just like you don't
need to write assembler to run stuff on "native" platforms.
> So try to battle for and have fun with Quorra and kinds even if it
> isn't the standard now and, even, if she is in some others camp and
> even if it isn't the Webby web, since it is reality anyway.
If it isn't "webby", it probably does not have a place (directly) on the
web platform. But maybe other platforms than the web have a future, and
it may live there.
> The progress is in variety the best progress is in ubiquitous and Open
> variety, which you are denying, in this case - by your own, Mozilla's
> cost as the two serious enough competitors has gone with the faster,
> easier for newcomers like desktop gamemakers and, even, proven by
> previous attempt - Java - tech.
You have not proven yet that once all those technologies are more
mature, they would be faster or easier, you just took that for granted
while that may not even be true.
And right now, more and more game makers are actually switching from
more "native" technologies to more "web" technologies - even though
things like WebGL are not completely mature in their implementations and
not that widespread yet. Give it a bit more time, and I actually think
they'll find that technology faster and easier to work with than some of
the stuff they used previously.
> I'v honestly thought that you are one of the greatest developers on
> most of Mozilla's tech as i'v seen your comments and answers as from
> Mozilla team - everywhere.. no, really.
Thanks. I'm probably somewhere in a diffuse middle management but
developer-affine position, mainly doing crash analysis but on the side
caring about a whole lot of where the open web and Mozilla is going,
including efforts I discuss about and support strongly, e.g. B2G. :)
> for other example the B2G isn't even in Mozilla repository, that
> should mean that it isn't Mozilla's Mainland project?
It's an experiment right now, and Mozilla has always been consisting of
many different projects and efforts that all support the mission in
their way - now more than ever, as the web moves faster and innovates
more than ever before and to keep it open, we need to be a player in
multiple ways there. Just like there is not one "Mozilla repository",
there is no "Mainland project" - but if anything comes close, it's
Firefox (desktop and mobile versions) right now.
ya knygar
> So do Java applets. To run one, you need to have some Java _bytecode_, not Java _source_.
Java isn't included into Google web browser and OS by default, NaCL
is, and if it would be in Mozilla, that would be a deal that i would
like to use.
> So any language you can compile to Java bytecode (e.g. anything in the list at http://en.wikipedia.org/wiki/List_of_JVM_languages ) can be run in an applet.
the list of JVM possible langs is impressive by numbers but in most of
these implementations, even so there are considerably mature variants
- you have restrictions that could set more implications on porting
than NaCL approach, i think. I don't like Java personally so i don't
know much of its additional benefits, i do like Python to some degree
so here is the example that i know:
https://code.google.com/p/unladen-swallow/wiki/FAQ
"Q: Why branch CPython? Why not use Jython, IronPython or PyPy?
A: We looked at that. We wanted to offer Google Python applications
better performance, and we obviously don't want to do more work than
we have to. However, Google has a massive body of C++ code exposed to
Python applications via SWIG, none of which would work with any of the
other Python implementations. Google has many of these systems
implemented in Java, too, but the people on the hook for these
applications were uncomfortable with that much change in their code
base; porting to Jython and Java infrastructure would not have been a
small change, and the app owners don't want to be paged at 3AM if they
can help it.
Ultimately, the reason for working off of CPython is compatibility:
compatibility with pure-Python code, and also compatibility with the
vast array of C extension modules in production."
> So because someone tried to do something really hard that people didn't really want all _that_ much and failed means that someone else will succeed at it?
> I'm not sure I follow the logic, honestly.
the logic is not that in mine tastes but in many actually existing
gaming engines like that UE3 that is written in C++ among other and
C++ won't make it into JVM without very heavy and unpleasant porting,
if at all, as far as i know. The situation is proven by the actual
interest in new Flash solutions by huge gaming engine developers. That
developers with that C++ engines wouldn't go to the WebGL anytime soon
as i understand from the situation. Adobe has not a real solution
currently released, so the NaCL now - could and should compete,
because it is open source and could make into standard with Mozilla's
support, that's what i think.
I need to comment that "people didn't really want all _that_ much and
failed" isn't true in my logic because i see that people do have the
millions if not billions of JVM out there (from stats), also - pretty
the same, impressing and proving the demand - amount of Flash players.
I think (i know from comments of developers etc.) that Browser Vendors
doesn't actually want Java and Flash, for various reasons. But Google
is developing the considerably better solution and developed it now -
to the production level, so it is in Chrome 14(latest stable) three
clicks away or kind, maybe even on by default for the Chrome App
Store.
Is my logic understandable now?
@Joshua Cranmer
> The JVM was explicitly designed with the goal of being cross-platform, and it has become a well-targeted platform for language development, as well as a well-researched one. As far as I know, the JVM is capable of equaling or exceeding native performance in code, except at native interface barriers. It also has the tremendous advantage of pretty much universally working right now in every major browser on most platforms (except those which forbid the JVM at all, snark snark).
I agree with that statement.
But, you see the sued by Oracle - Google, do you think anyone else
would try to implement, for example - OpenJDK into their web browser?
> By contrast, PNaCl is targeting a relatively new architecture, and an architecture for which these kinds of cross-platform abilities is not an explicit design goal. For an explicit discussion of this, see the "LLVM IR is a compiler IR" thread in llvm-dev mailing list, started on October 4 of this year.
I'v seen it, though not a whole discussion, then i'v seen the
www.phoronix.com/vr.php?view=OTk2Nw post that tried to sum up a bit
and i took a rest, as, anyway, i don't have enough qualification in
that VM's to comment something on that topic, though i am still
positive for the idea.
I'm talking more about Codename 'PNaCL' that provides the secure
enough sandbox and that cross-platform goods. I'm talking about demand
of the current market that i see, not so - about the particular NaCL
or PNaCL as a "take it while it's hot" solution. I'm not a dev or PR
of it, i simply want to see the Native Web Gaming experience in the
browser not from the closed Flash but from the open something. I have
tried to explain why i think that clever Native Code environment by
the best world specialists like Google and Mozilla has (i think) -
won't ruin the Web worse than these plug-ins ruined/ing it already.
Still can't understand why there weren't a one browser developer that
is on my side of view, but i could prove by comments of developers and
gamers that such a system is needed and awaited. That proves that Java
isn't enough even if it would be completely firmwared into the
browsers and Flash.. Adobe Flash has another chance now - for the next
round except of finally
- go with HTML5 (not that with Flash to HTML5 translator), except of
supporting the 'HTML5' for graphics. From the latest Adobe news i
think - maybe they would go bravely and give away the part of common
Flash usecases in favor of the good JS-HTML5-CSS3 IDE. Maybe they are
doing that right now. They are focusing on gaming and calling the
Flash - "The Next-Generation Console". There are so many gamers that
Flash would remain in most of your devices, there are so many Android
devices and they are targeting them - calling that Linux support, i
have posted the link. So - we would still have the very large amount
of Flash plug-ins.. That would mean increasingly - the DRM for the
content that may be ok for someone and closed source my otherwise
Linux-libre PC that i was only recently being able to power with nice
old-version though open source Flash plugin to watch most of the Ads(i
like ads) and video.. that isn't ok for me.
I didn't like this situation and can't understand why you are -
educated, clever people, actually Web developers and even Mozilla
Browser developers like it so much that you'd rather insist on JVM or
JS For All instead of trying to liberate the core of the Web that
right now gets to users displays - providing the best replacements for
the existing popular but closed source solutions.
There was so many kudo's to WebGL instead of old-school Flash (excuse
me if i write to much to easily read it but i feel the real need to
share the point) all over the web that only it shows -- the direction
of integrating such a things into browser is right. By WebGL Mozilla
have already won over the old-school Flash (IMO), so now - Adobe makes
the next step and.. Browser vendors would again - leave the people
waiting the realization of the needs? No, Chrome proposed and
implemented the variant.. along with WebGL BTW.. so now the Mozilla's
turn, as i see it.
thanks for the answers, anyway.
> There might be room for a better language on the web than JS. PNaCl is not that language.
i only recently realized (finally - after the Google Dart
announcement) that one language for Web is bad and ain't work actually
as you see these and other plug-ins and web(in browsers) lang
propositions, so, consolidation for some unified environment instead
of the language itself - is what i see - large corporations are doing
right now and what i'd like to see from this considerably open
corporations - like Mozilla.. and that, considerably praised
corporation like Google.
Boris Zbarsky
> Java isn't included into Google web browser and OS by default
And NaCL is not included into _any_ web browser by default.
Why do you think universal NaCL adoption would be simpler or better than
universal Java adoption?
> NaCL is, and if it would be in Mozilla, that would be a deal that i would
> like to use.
Why do you think NaCL is a better fit for what you want to do than
compiling to the JVM or to JavaScript?
Do you actually have data to back this up? Or are you just looking at
the new shiny and wanting it and wasting people's time as a result? So
far, honestly, my impression is the latter.
> the list of JVM possible langs is impressive by numbers but in most of
> these implementations, even so there are considerably mature variants
> - you have restrictions that could set more implications on porting
> than NaCL approach, i think.
PNaCL will have very similar restrictions if it ever happens. That's
just life if you actually want to create portable code.
NaCL without the "P" part is so actively bad for the web (hardware
vendor lock-in!), that I'd appreciate it if we just don't discuss it in
this context.
> Ultimately, the reason for working off of CPython is compatibility:
> compatibility with pure-Python code, and also compatibility with the
> vast array of C extension modules in production."
OK, but how would this be better with PNaCL, unless every single one of
those modules is rewritten to be compilable to whatever restricted
subset of LLVM PNaCL ends up having to use?
Seriously, there's no free lunch here. If you want execution in a
VM-like environment (that includes security restrictions!) and
portability for C code then either you emulate the hardware or you
restrict the allowed code constructs a good bit. The former is
emscripten; the latter is compiling C to the JVM or to the PNaCL
so-far-vaporware.
> the logic is not that in mine tastes but in many actually existing
> gaming engines like that UE3 that is written in C++ among other and
> C++ won't make it into JVM without very heavy and unpleasant porting,
> if at all, as far as i know.
OK, what makes you think that they can be done via PNaCL without such
porting?
> currently released, so the NaCL now - could and should compete,
> because it is open source and could make into standard with Mozilla's
> support, that's what i think.
As I said above, NaCL in its current is actively bad for the web because
it enforces hardware platform lock-in. We (Mozilla) should certainly
not be supporting it; we should be opposing it, because it is the
antihesis of what we stand for. In my opinion; others may disagree, of
course.
> I need to comment that "people didn't really want all _that_ much and
> failed" isn't true in my logic because i see that people do have the
> millions if not billions of JVM out there
Not on the web, so much...
> I think (i know from comments of developers etc.) that Browser Vendors
> doesn't actually want Java and Flash, for various reasons.
Yep.
> But Google is developing the considerably better solution
It's not better, because it still fails the basic "does not create
lock-in" test.
> Is my logic understandable now?
Yes, I think so; I think we just fundamentally disagree on the basic
premises about what a good outcome for the web is and that you
underestimate the amount of porting pain PNaCL (again, if it ever
happens) will involve.
-Boris
ya knygar
> If it isn't "webby", it probably does not have a place (directly) on the web platform. But maybe other platforms than the web have a future, and it may live there.
reality aware and now, after the death of the only big IT leader that
was publicly against the Flash (and Java as well), i can't see what
would stop this or these from building the next AR Web as some kind of
AR Net like they could and maybe, even, like to -- as they would have
that performance for that kind of AR experience, that Mozilla's
platform may not leverage..
The same goes to "Google's view" on the Web.
So - Mozilla as always was - almost the only place that could secure
the worlds web situation and i can't receive the single one comment
that would at least give a chance of that Mozilla's people understand
the treat.
I'm aware of the WebGL/CL capabilities (now getting aware of
http://brendaneich.com/2011/09/capitoljs-rivertrail/ that seems like
"close to exploiting massively parallel hardware from JS, without
having to write WebCL and risk terrible safety and DoS bugs")
and i have proposed to the w3.org/community/ar - the Mozilla's
platform as a reference for the implementation. WebGLetc. seems enough
for a simple experiences, for building the AR Web, but not enough to
compete with the near-future Flash platform and that, alone, could
lead to the huge consequences, i mean it - for the 'Open Web'. That AR
stuff is much closer to the mass usage than most of people currently
think, i guess.
@Boris Zbarsky
> And NaCL is not included into _any_ web browser by default.
[ http://chrome.blogspot.com/2011/09/new-stable-release-of-chrome-expanding.html
]
they say "Native Client only supports applications listed in the
Chrome Web Store, but we are working to remove this limitation as soon
as possible."
the work around to enable the NaCL 'everywhere' is in two clicks..
heh - just found another developer - supporting NaCL --
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=66394
I think the limitation would be worked out pretty much soon, if the
App Store isn't enough to take it seriously.
> Or are you just looking at the new shiny and wanting it and wasting people's time as a result? So far, honestly, my impression is the latter.
i can say the opposite - you have wasted mine, as you aren't reading
or not bothering to understand the posts before asking the questions
-- and i try to answer all - because i have started the thread.. so
what ?
=) we all may or may not read something if we wish, isn't hard, isn't it?
> Why do you think NaCL is a better fit for what you want to do than compiling to the JVM or to JavaScript?
flash says that it's in C, if i understood correctly -- that means the
kind of the NaCL approach, if not - just a next Alchemy but,
certainly, i can't believe that - that level of detail could be ran in
JS at that speed. And even if it is -- again, almost all game devs
have the engines in C/C++, why they would convert it to JS or JVM, for
what? In the end it was Epic's demonstration and they are pretty solid
company to try amuse people with something that aren't actually
working as they say -- on the real, consumers level, moreover they ran
it in Firefox =)
> Do you actually have data to back this up?
their time to implement it for App Store -- it's good enough for me.
If you mean -- stats with performance comparison -- no, i haven't seen
yet, but the NaCL people say the 5% difference from the native code
(C/C++ i guess) , and i see the .. sometimes huge difference of JS vs
C++
here - http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=v8
No miracles, that is predictable, logically approved.
> PNaCL will have very similar restrictions if it ever happens. That's just life if you actually want to create portable code.
innovative and in many ways better.
2. this - http://www.ogre3d.org/forums/viewtopic.php?f=4&t=66394 - man said
"The idea is to compile c and c++ and in a special way, a protected
way, a cross platform way.
Google released an SDK for NaCl that includes a compiler, "c run time"
h files and libraries –in a form that is similar to Linux gcc and its
accompanied files, so compiling existing project that already compile
for Linux is not that hard."
"The advantages of NaCl over javascript are that native assembly code
will always run faster then javascript and you can reuse existing code
that you wrote for game in c++ to run safely in the browser."
he did the actual demo, i believe him.
> NaCL without the "P" part is so actively bad for the web (hardware vendor lock-in!), that I'd appreciate it if we just don't discuss it in this context.
http://blog.chromium.org/2011/08/native-client-brings-sandboxed-native.html
"The next milestone for Native Client is architecture independence:
Portable Native Client (PNaCl) will achieve this by using LLVM bitcode
as the basis for the distribution format for Native Client content,
translating it to the actual target instruction set before running.
Until then the Chrome Web Store will be the only distribution channel
for Native Client apps. This will help us ensure that all Native
avoid the spread of instruction set architecture dependent apps on the
blog."
that is the data and i believe that data.. Google Chrome wasn't that
platform of high experimentation if it isn't leading to real -
profitable resource, i can't see why it suddenly changes.
> Seriously, there's no free lunch here. If you want execution in a VM-like environment (that includes security restrictions!) and portability for C code then either you emulate the hardware or you restrict the allowed code constructs a good bit. The former is emscripten; the latter is compiling C to the JVM or to the PNaCL so-far-vaporware.
time.. but i'd rather - suggest latter to Mozilla, as it is what uses
their direct competitor.
> As I said above, NaCL in its current is actively bad for the web because it enforces hardware platform lock-in. We (Mozilla) should certainly not be supporting it; we should be opposing it, because it is the antihesis of what we stand for. In my opinion; others may disagree, of course.
milestone for Native Client" above and consider it as a real going
plan that Mozilla need to catch up to be cool and with
interoperability, instead.
> I need to comment that "people didn't really want all _that_ much and
> failed" isn't true in my logic because i see that people do have the
> millions if not billions of JVM out there
> Not on the web, so much...
considered as - on the web -- see
https://www.adobe.com/products/flashplatformruntimes/statistics.html
"Percentage of internet-enabled PC's" they state.
> It's not better, because it still fails the basic "does not create lock-in" test.
to ratify the deal, if you wish - any Web tech from standard or not -
could be the lock in.. i consider the CSS 3D transformations as the
lock-in currently as they work on iOS but not on Mozilla Mobile. And
otherwise WebGL works on Mozilla Mobile but not in iOS.. You could
always wait for the better solution or some JS compilers magic but i
don't want to.. what i propose - i'm sure - would be good for this
Web, for next one, and actually for people that simply want the things
like Quake Live on theirs work-place computers =)
> Yes, I think so; I think we just fundamentally disagree on the basic premises about what a good outcome for the web is and that you underestimate the amount of porting pain PNaCL (again, if it ever happens) will involve.
than to learn JS for someone who loves C++ that tool -- would be right
for the job?
azakai
>
> > Why do you think NaCL is a better fit for what you want to do than compiling to the JVM or to JavaScript?
>
> the man from the latest Adobe MAX that presented the UE3 engine for
> flash says that it's in C, if i understood correctly -- that means the
> kind of the NaCL approach, if not - just a next Alchemy but,
> certainly, i can't believe that - that level of detail could be ran in
> JS at that speed.
JS engines should be able to match or exceed the performance of Flash.
And we have Emscripten which does for JS the same as Alchemy does for
Flash. So you can compile a C/C++ game engine into JS just like you
can do for Flash.
- azakai
Boris Zbarsky
> it is in my Google Chrome, and in yours if you have it auto-updated,
> they say "Native Client only supports applications listed in the
> Chrome Web Store, but we are working to remove this limitation as soon
> as possible."
> the work around to enable the NaCL 'everywhere' is in two clicks..
> i can't believe that - that level of detail could be ran in
> JS at that speed.
performance. I'm very interested in data, though.
> And even if it is -- again, almost all game devs
> have the engines in C/C++, why they would convert it to JS or JVM, for
> what?
>> Do you actually have data to back this up?
>
> you mean - the prove?
indicate things. That's a much lower bar than "prove".
> the prove is in that Google Chrome team wasted
> their time to implement it for App Store
> If you mean -- stats with performance comparison -- no, i haven't seen
> yet, but the NaCL people say the 5% difference from the native code
> (C/C++ i guess) , and i see the .. sometimes huge difference of JS vs
> C++
> here - http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=v8
We believe that JS can run significantly faster than V8 runs it right
now, and are actively working on that.
>> PNaCL will have very similar restrictions if it ever happens. That's just life if you actually want to create portable code.
>
>> OK, what makes you think that they can be done via PNaCL without such porting?
>
> 1. but it would be open source by the start
good luck getting your changes into it, given how other such projects
seem to work...
>- likely to be more innovative and in many ways better.
> 2. this - http://www.ogre3d.org/forums/viewtopic.php?f=4&t=66394 - man said
> "The idea is to compile c and c++ and in a special way, a protected
> way, a cross platform way.
> Google released an SDK for NaCl that includes a compiler, "c run time"
> h files and libraries –in a form that is similar to Linux gcc and its
> accompanied files, so compiling existing project that already compile
> for Linux is not that hard."
I already pointed out the major problem with NaCl from a web point of
view....
> "The advantages of NaCl over javascript are that native assembly code
> will always run faster then javascript
For example, "native assembly code" does not always run faster than Java
runs on the JVM...
The point being that JavaScript is likewise compiled to "native assembly
code".
Now compiling C to JavaScript will almost certainly give you worse
performance than compiling it to native code directly, but the gap is
already only 2x for a number of programs (comparing to gcc -O3). And
that's with today's SpiderMonkey. We can do better, and plan to.
Yes, I'm aware of the state of the NaCl world.
Again, what's shipping right now is bad for the web. The
architecture-independent part is vaporware so far; we'll see whether it
ever happens and if so how well it works.
> and in the meantime avoid the spread of instruction set architecture dependent apps on the
> web.
> BTW the hardware emulation is very good now as i'v seen that last
> time.. but i'd rather - suggest latter to Mozilla, as it is what uses
> their direct competitor.
> Sure, i'm with you for interoperability, please read about that "next
> milestone for Native Client" above
don't know how to solve it yet.
>> It's not better, because it still fails the basic "does not create lock-in" test.
>
> they are open source
> i consider the CSS 3D transformations as the
> lock-in currently as they work on iOS but not on Mozilla Mobile.
> And otherwise WebGL works on Mozilla Mobile but not in iOS..
That's not the same situation as x86-compiled NaCl. Try running that on
an ARM chip.
> You could always wait for the better solution or some JS compilers magic but i
> don't want to..
(for what is at the moment a "we have no idea how to really make it
work" research project, as far as I can tell) will be smaller than the
wait time for in-progress JS compiler work that's well understood and
happening right this second?
> but do you agree that if that pain would eventually be the lesser pain
> than to learn JS for someone who loves C++ that tool -- would be right
> for the job?
-Boris
ya knygar
ATTENTION: please - don't read this post if you assume that i'll waste your time
NOTE: i like JS, i love Mozilla, i'm not a hater of any of your open
source work, i use some of it every day and i'm every day thankful for
this, promoting JS and Mozilla whenever it is appropriate!
I can't reply to all the statements but i would try to the most
important points that i see.
@Boris Zbarsky
>I don't follow. What competitor.
All your latest post makes me happy that i'm staying with Mozilla, i'm
glad for CSS 3D, i'm glad that you'r so positive in Mozilla for
competing the Google's V8, PNaCL and other innovations.
@azakai
> Why not?
> JS engines should be able to match or exceed the performance of Flash.
> And we have Emscripten which does for JS the same as Alchemy does for
> Flash. So you can compile a C/C++ game engine into JS just like you
> can do for Flash.
As i understand - you are the Emscripten developer,
wow, great project,
why haven't you explained that you'r the dev of Emscripten and you
have such a Flash11-alike solution in the first post?
..
back to the topic of *NaCL vs Flash vs Mozilla's platform.
"The downside is that Emscripten compiled code is currently about 20
times slower than NaCl. However, at this early stage, there is plenty
of room for optimizations. We should see that gap narrow over the
next few months."
that was 2010/09 article.
i'm completely ok with it, it was a year ago.
later there was an infringed Doom demo
https://developer.mozilla.org/en-US/demos/detail/doom-on-the-web/
about that you'v said in
http://syntensity.blogspot.com/2011/05/followup-to-doom-on-web.html
"So please don't run this demo, be disappointed by the speed, and say
"JavaScript is too slow, we need Flash/NaCl/Java/native apps" etc. The
demo can't be used to conclude anything like that."
but what i want to know for the date -- could you now say -- if that
"20 times slower than NaCl" you think, predict, or else -- could be
worked into 1x slower? or even faster?
That is very important for me, as you may see..
-
if so..
as i don't have nothing against and only pro - Emscripten as an
approach if it could soon enough - be as fast as NaCL or possibly -
Flash's view on NaCL(if ever)
-- your work would make me really happy and i could rest a bit on my
worries about Mozilla's future as a gaming platform.
Currently, though -
just logically -- the approach of compiling something into bytecode,
than - compiling into JS looks to me, just logically - not as fast as
running that bytecode in the first place, in some proper, universal
bytecode execution environment like i think - *NaCL or similar - could
be.
Let's throw away the possible IE, Opera and Safari denial and just
review the possibility.
as Boris said
choice of one 3D card over other, meant - the choice of one Vendor
over another. I don't want the Mozilla to be another vendor so for me
- even 5-10% in 3D performance matter.
I understand that modern gaming world with all that *equal*
consoles/pc ports - doesn't chasing the graphics and you easily could
play most of the games on max on a 2 years old medium card. However -
for the Augmented Reality with all that ARM's in a pocket - you'll
again need the best possible performance, when even 10% matter for the
experience, as experience itself aiming to match *reality* and all
this - closely in front of your eyes, in AR glasses and that differs a
lot from monitors/tv's in a couple of meters. Also - i think from what
i see as a possible next-gen console graphics -- the current
graphical war pause - is only the pause and with the next consoles
coming it would again be the big battle of small details.
If you care - i can't rest completely on this case (Mozilla's future
as a gaming platform) because - the Emscripten, even with all the
coolness (as i see) haven't been backed by such a serious gaming
industry players like Epic.. more of it - in next paragraphs. But for
now -- some free, open source converted C++ games examples, some
respectful to the achievement - hype from Mozilla -- might stop the
game devs that i know and others that i'v just seen the comments from
-- from choosing the currently considerable -- Adobe Flash platform.
Kudos, anyway.
@Jeff Gilbert
> If it's playing in Flash, but written in C, it was compiled over by Alchemy.
I need to explain that - at first look - before i'v started this topic
- i assumed that the next Alchemy (that likely to power that
presentation from all the logic here) needs to be not a C/C++ to AS
translator (even if with some "inlined bytecode") but a more powerful
tech that somehow creates the type of environment like PNaCL want to
do -- as i thought that i'v heard from the live presentation that
they actually run C++ in some sandbox.. that gave me the NaCL picture
=)
..Maybe i have just misleadingly disbelieved the Adobe's AS compilers
and Adobe's potential to compete - at least with WebGL and that demo
created so much WOW..
i have tried to investigate a little, on this:
1. the man who have made the Flash UE3 presentation on Adobe Max
is Tim Sweeney
https://en.wikipedia.org/wiki/Tim_Sweeney_%28game_developer%29
"founder of Epic Games"
serious game developer that know a good bit of building the solid
gaming platforms, i think.
Also wiki says "Sweeney is an advocate of open source software, and
has repeatedly voiced his opposition to software patents." =)
here is that video, hand-recorded on MAX-
http://www.youtube.com/watch?v=L6KFF30Cw5M
(there are real-game presentation with some bots for these who want a
slightly better prove)
i'v listened again (i constantly use Tor Browser Bundle that by
default - creates small circumstances in watching YouTube, so it took
a time for me.)
what he says is that they had the C++ compiler in a secure sandbox of
Flash and they use some provided OpenGL libraries (he means
https://www.adobe.com/devnet/flashplayer/stage3d.html API's maybe,
that as i understand are pretty similar to WebGL API's.. any
comments?)
@azakai
hello again :)
i understand that
that presentation could mean -- Emscripten/Alchemy2 approach of Adobe
and that is it, they are good with it..
..throwing away the possibility of Adobe going the 'pure' PNaCL way..
Do you think - that - showed in camrip quality demo -
that being showed in HD here - http://www.youtube.com/watch?v=UQiUP2Hd60Y
that is *possibly* the Alechmy2 working with Stage3D API's
-- could be enabled soon by Emscripten with WebGL/CL acceleration for
Mozilla Firefox stable?
How soon if so?
-
If so -- i'm already saying - cool - as the Mozilla's plans is easier
to understand, with the Emscripten bit in puzzle.
Now I hope - some game developers, with your help, could introduce the
real potential of JS/WebGL gaming platform and prove that Flash 11
goods has a real competition in Open camps.
What do you think of developing the demonstration (maybe on base of
some floss C++ game) that would show the C++ games/engine's developers
- that they have a good choice from Mozilla?
I think it is a great time.
@Jeff Gilbert
> Physics can be computationally intensive, AI can be intensive, but rendering an empty level as a tech demo is not. You severely overestimate the roll of the CPU in game performance, triply-so for tech demos. You talk about how game graphics need a native-level of performance, but they already have that (more or less) in WebGL.
if we right about that Alchemy is Alchemy much like the Emscripten and
that's all Adobe has - yes, it really like a mountain from a
shoulder.. i think it would be a great News for many people who
doesn't know yet of Emscripten and think that they would have again to
deal with the same old ..plug-ins.
About the WebGL - what i seen as a WebGL 'big' products (like RO.ME or
Mozilla's "..Navigator" etc.) is far from what i'v seen in thus UE3
demo, not so far, but far enough to consider the WebGL alone (due to
Emscripten absence or due to River/CL absence, whatever) -- not that
'native gamin' experience' gaming platform and choose Flash for that,
due to a hype or support by respected game devs.
Glad about your positive, would be happy when the market would prove
that my worries were not necessary.
Sadly - seems like even respected businesses doesn't currently realize
what they miss, maybe that is more like Mozilla's/Google's marketing
problem..:
I'v looked at http://www.unrealengine.com/insiderblog/unreal_engine_3_comes_to_flash
found there the
https://twitter.com/#!/markrein
he is the
"Vice President and Co-Founder of Epic Games."
i'll re-post the small conversation here:
"Benjammin1110 Benjamin Daniel Lake
@MarkRein arnt most internet browsers dropping flash? Or did I make
that up? Would something similar be do-able in html5? I'm a noob to
this
13 Oct"
"MarkRein Mark Rein
@Benjammin1110 No HTML5 isn't capable of delivering that kind of
performance or feature. But still cool tech for much lesser games.
13 Oct"
"Benjammin1110 Benjamin Daniel Lake
@MarkRein ah sweet, I was unsure about it, thought it was just a
'better' version of flash so to speak, amazing tech you guys are
doing!
13 Oct"
----
Let me sum it all up with a couple of statements as a result of this discussion:
1. Adobe's Web competition: Emscripten + WebGL/CL would provide the
performance comparable
to that Alchemy(2) + Stage3D and by that - could directly compete with
Adobe Flash,
am i right on this?
2. Chrome Web competition: Mozilla don't want to introduce the similar
to PNaCL tech - by that - leaves that competitor to built it's own web
gaming solution that, eventually, may be faster/easier solution than
what Mozilla(/Adobe) now has or publicly plans,
am i right on this?
thank you in advance.
On Sat, Oct 15, 2011 at 11:08 AM, ya knygar <kny...@gmail.com> wrote:
> i think you have largely misunderstood that conversation and what i'm
> trying to discuss,
> anyway - for me - any response on the topic is important as i care
> about that topic and
> unless you'll show that i am all wrong on it by facts not an
> authoritarian dismiss of my opinion,
> like now, i certainly won't go away from the topic, thought, i have no
> plans to create some another
> threads as that topic is what i care for now.
>
> If you'll have the real, motivated opinion about Native Code that for
> some Mozilla's reason
> couldn't go on pair with WebGL and JS tweaking,
> please - explain it, so people watching there - would understand that
> situation better.
>
> take care.
>
> On Sat, Oct 15, 2011 at 12:38 AM, Benoit Jacob <jacob.b...@gmail.com> wrote:
>> [replying off-list]
>>
>> This whole discussion thread is useless and only shows that you 1)
>> have lots of time 2) don't know what you're talking about.
>>
>> My problem is that it's causing several people to waste time reading
>> and replying to.
>>
>> Please stop this kind of threads.
>>
>> Benoit
>>
>> 2011/10/14 ya knygar <kny...@gmail.com>:
>>> ]
>>> they say "Native Client only supports applications listed in the
>>> Chrome Web Store, but we are working to remove this limitation as soon
>>> as possible."
>>>
>>> http://www.ogre3d.org/forums/viewtopic.php?f=4&t=66394
>>>
>>> I think the limitation would be worked out pretty much soon, if the
>>> App Store isn't enough to take it seriously.
>>>
>>>
>>>
>>> i can say the opposite - you have wasted mine, as you aren't reading
>>> or not bothering to understand the posts before asking the questions
>>> -- and i try to answer all - because i have started the thread.. so
>>> what ?
>>> =) we all may or may not read something if we wish, isn't hard, isn't it?
>>>
>>>
>>>
>>> flash says that it's in C, if i understood correctly -- that means the
>>> kind of the NaCL approach, if not - just a next Alchemy but,
>>> JS at that speed. And even if it is -- again, almost all game devs
>>> company to try amuse people with something that aren't actually
>>> working as they say -- on the real, consumers level, moreover they ran
>>> it in Firefox =)
>>>
>>>
>>>
>>> their time to implement it for App Store -- it's good enough for me.
>>> yet, but the NaCL people say the 5% difference from the native code
>>> C++
>>> here - http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gpp&lang2=v8
>>>
>>>
>>>
>>>
>>> "The idea is to compile c and c++ and in a special way, a protected
>>> way, a cross platform way.
>>> Google released an SDK for NaCl that includes a compiler, "c run time"
>>> h files and libraries –in a form that is similar to Linux gcc and its
>>> accompanied files, so compiling existing project that already compile
>>> for Linux is not that hard."
>>> that you wrote for game in c++ to run safely in the browser."
>>>
>>> he did the actual demo, i believe him.
>>>
>>>
>>> http://blog.chromium.org/2011/08/native-client-brings-sandboxed-native.html
>>> Portable Native Client (PNaCl) will achieve this by using LLVM bitcode
>>> as the basis for the distribution format for Native Client content,
>>> translating it to the actual target instruction set before running.
>>> Until then the Chrome Web Store will be the only distribution channel
>>> avoid the spread of instruction set architecture dependent apps on the
>>> blog."
>>>
>>> that is the data and i believe that data.. Google Chrome wasn't that
>>> platform of high experimentation if it isn't leading to real -
>>> profitable resource, i can't see why it suddenly changes.
>>>
>>>
>>> time.. but i'd rather - suggest latter to Mozilla, as it is what uses
>>> their direct competitor.
>>>
>>>
>>> plan that Mozilla need to catch up to be cool and with
>>> interoperability, instead.
>>>
>>>> failed" isn't true in my logic because i see that people do have the
>>>> millions if not billions of JVM out there
>>>
>>>> Not on the web, so much...
>>>
>>> considered as - on the web -- see
>>> https://www.adobe.com/products/flashplatformruntimes/statistics.html
>>> "Percentage of internet-enabled PC's" they state.
>>>
>>>
>>> to ratify the deal, if you wish - any Web tech from standard or not -
>>> lock-in currently as they work on iOS but not on Mozilla Mobile. And
>>> otherwise WebGL works on Mozilla Mobile but not in iOS.. You could
>>> Web, for next one, and actually for people that simply want the things
>>> like Quake Live on theirs work-place computers =)
>>>
>>>
>>> than to learn JS for someone who loves C++ that tool -- would be right
>>> for the job?
>>>
azakai
>
> back to the topic of *NaCL vs Flash vs Mozilla's platform.
>
> "The downside is that Emscripten compiled code is currently about 20
> times slower than NaCl. However, at this early stage, there is plenty
> of room for optimizations. We should see that gap narrow over the
> next few months."
> that was 2010/09 article.
>
slower than native code. See the slides here for example,
http://syntensity.com/static/jsconf_eu_Emscripten_lo.pdf
That 3X-4X should continue to improve substantially as JS engines
improve. I see no reason why we cannot get very close to the speed of
languages like Java or C# given the current trajectory.
>
> Currently, though -
> just logically -- the approach of compiling something into bytecode,
> than - compiling into JS looks to me, just logically - not as fast as
> running that bytecode in the first place, in some proper, universal
> bytecode execution environment like i think - *NaCL or similar - could
> be.
aside from initial parsing speed. And initial parsing speed is
negligible for the things we are talking about here (game engines).
2. There is no "universal bytecode" that runs everything fast. The
JVM, .NET and NaCl run statically-typed code fast, but run dynamically-
typed code slowly (due to lack of PICs and so forth) - no dynamic
language on those static-language VMs comes close to the fastest
native dynamic-language implementations. So every bytecode/VM/platform
is a compromise. And note that many game engines embed a dynamic
language for scripting, so this is an actual compromise in the case we
are talking about.
>
> i understand that
> that presentation could mean -- Emscripten/Alchemy2 approach of Adobe
> and that is it, they are good with it..
> ..throwing away the possibility of Adobe going the 'pure' PNaCL way..
>
> Do you think - that - showed in camrip quality demo -
> that is *possibly* the Alechmy2 working with Stage3D API's
> -- could be enabled soon by Emscripten with WebGL/CL acceleration for
> Mozilla Firefox stable?
>
bound by GPU speed, not CPU, as others have mentioned. And there are
already WebGL demos that look just as good, for example,
http://blog.tojicode.com/2011/10/source-engine-levels-in-webgl-video.html
I see no reason why a game engine couldn't be compiled from C or C++
to JS and give results similar to those, right now. In fact if there
are game engine devs reading this, I would be very happy to work with
you to use Emscripten to port your engine to the web.
- azakai
Henri Sivonen
> back to the topic of *NaCL vs Flash vs Mozilla's platform.
multi-vendor technologies that have multiple independent
implementations. WebGL&JS works in Firefox, Chrome, Opera and (if a
pref is set) in Safari.
NaCL and Molehill are single-implementation technologies.
ya knygar
>multi-vendor technologies that have multiple independent
anyway - thank you.
I call it there - Mozilla platform because i care there - implicitly
about what is in Mozilla platform, of what it would be capable in
comparison to other competing web platforms.
Maintaining the conversation for all around and their plans for is too
tricky so i, by intend - dropped the 'whole-around' and focused on
what i'm really interested.
> NaCL and Molehill are single-implementation technologies.
even an interoperable plug-in, ATM.
@azakai
> 1. Compiling into bytecode vs. source has no effect on performance,
> aside from initial parsing speed. And initial parsing speed is
> negligible for the things we are talking about here (game engines).
positive, as you state the possible
> Java or C#
speeds and if the porting from C++ would be relatively easy,
that should be a great achievement for all JS community!
> 2. There is no "universal bytecode" that runs everything fast. The
> JVM, .NET and NaCl run statically-typed code fast, but run dynamically-
> typed code slowly (due to lack of PICs and so forth) - no dynamic
> language on those static-language VMs comes close to the fastest
> native dynamic-language implementations.
top of their performance - being the fastest that among these for
dynamic.
just passed by the
http://arstechnica.com/business/news/2011/10/javascript-has-problems-can-googles-dart-solve-them.ars
statement:
"But there's a big difference between "the fastest scripting language"
and just plain "fast." Compared to traditional compiled languages like
C++ or Fortran, or even JIT-compiled safe languages like C# and Java,
JavaScript's performance looks a lot less impressive. For all the
time, money, and effort that has been poured into JavaScript engines,
JavaScript programs still perform at a huge disadvantage relative to
those built with typical desktop development tools."
i won't comment on that.
i would comment on JS -- i really like what JS have done to the
Browsers and how you are moving towards with it,
moreover - i really prefer the easier programming that these
dynamically typed languages introduced to the world (how ever it
relates to the typing system),
you know there is a lang called Ruby, i'm not using it 'coz i don't
like some nuances of it
but what i respect from it is that Ruby's way is in - "people are
more important than machines"
-- translating it on my opinion of JS improvement -- Mozilla (among
other, but, first of all - Mozilla) makes the deal, which many people
that would never use C/C++ because these would
always be too 'low-level' (by intent, by nature) and i dare to say -
the people that wouldn't try to program at all -- are now
- appreciating the high levelness and relative ease of JS (please,
don't bully me for using these terms here)
even so - with even even higher 'high-level' frameworks and libraries.
Probably, many amateur game developers would appreciate the JS choice
even more in the near future, and that is cool, for the certain part
of gaming market.
> So every bytecode/VM/platform is a compromise. And note that many game engines embed a dynamic
> language for scripting, so this is an actual compromise in the case we
> are talking about.
The recent Dart announce with that mixed typing was the last drop,
after which i realized that i need to write here and (with all my
believe and approve of WebGL's way) try to explain why i feel the real
worry about the whole aspect of competition with that Google's tech --
by JS, even if that's WebGL backed.
So - i feel and i think - just as you said - that the comparison of
these languages and approaches mentioned here
-- is in the area of the compromise.
As i understand it
- the wise compromise would be if Mozilla would support the kind of
PNaCL on pair with JS compilers perfection.
As i understand it now
- the realistic compromise - is that Mozilla doesn't support PNaCL natively,
introducing the situation like IE's support of WebGL >> you could have
it with a plug-in, with some reduced speed, or with another plug-in,
again with some disadvantages that would matter as for a gaming
platform.
Google is serious enough with that NaCL or that kind of approach, so
that is a weak position for Mozilla, that's what i all the road and
you answering that all is ok. Well, ok, so.
-- I don't want to be boring so it's time for the final conclusions
from this topic:
- Google - playing with Flash integration currently - because it adds
the stability to their platform and because - with a better Flash
integration (like now in Chrome) the Google's Web platform became -
all including for the best affords.
there aren't so much affords so it isn't so hard. If Google had owned
Java - the Java would had been the first class citizen in their web
platform, that's the simple opinion which i have.
- Google - clearly wants to have own Market for everything,
that is why they was so fast - the NaCL was included in stable as
another feature for their Chrome Store,
- eventually - Google would have everything they need to abandon the
Flash Web platform, like Apple did, Mozilla doing (by the 'HTML5').
So.. in some moment - Google finally would have Dart that - looking on
'low levelness' of it's code - IMO - could be faster than JS/ES and in
which JS could be compiled,
also they would have the faster C and C++ on the Web, by the *NaCL,
and of-course the V8 JS compiler would continue to evolve just as good
as Monkeys.
That is all what i see as an obvious points that eventually could lead
to the couple of web gaming platforms in which Mozilla could be not
strong enough.
- if something would go wrong with Emscripten adoption by big
developers, for example.
that big developers and what is pretty unique - the small and medium
one's also - are looking on everything now (i'v read) and still
considering - what 'Web' platform to choose so that it would cover the
mobiles and all..
The acquisition of the PhoneGap by the Adobe was a smart move if that
was for the goods of the more 'native' gaming, though - it's only my
presumption and all that may be for the different purpose -- of
supporting 'HTML5' :)
By absence of the strong pro-gaming position - Mozilla just would use
a bit - i suppose - a very large bit of users, though, as always - all
may be not so bad - and Mozilla should know it better in the end, and
possible - have the strong plans for it. That's what i end with, for a
positive.
> That is just a static scene being rendered. It is almost certainly
> bound by GPU speed, not CPU, as others have mentioned. And there are
> already WebGL demos that look just as good, for example,
> http://blog.tojicode.com/2011/10/source-engine-levels-in-webgl-video.html
yes, i'v seen it - it is on the you-tube suggestions list of that UE3 demos.
I'v seen two records of that demo - lagging and lagging less but it
comes due to the recording glitches he say.
He is - Brandon Jones and he also had a cool non-lagging Rage's WebGL
demo some time ago,
also - he wrote the
http://blog.tojicode.com/2011/08/frameworks-are-awesome-heres-why-i-dont.html
that i am considering - talking about the 'highest high level' above
in this post.
-----
Basically i'v had indirect answers on all my questions.
I suggest - describing the Mozilla's denial of one or another tech on
web-press and - to be more explicit in the process, backed by
arguments, by a couple of Mozilla's dev's not a one. I'v seen the
videos of Mozilla's dev's-managers discussions -- that is what i'm
talking about -- but on web-press it would be easier to understand.. i
just dreaming :)
What is more important i suggest - the public reviewing the arguments
from other Web Browsers camps. In the end - you are Mozilla, i think
you are brave enough to discuss everything, with all the con's and
pro's.
Also - if Mozilla would be better in a fast and insightful public
reaction to the initiatives like NaCL - such a threads like this would
became unnecessarily and you'll save people's time in figuring the
technologically, not that - ideologically or even politically - best
platform to develop for.
-----
Thank you all for the attention,
take care.