This article won't help much. Many people are saying this issue occurs without any plug-ins. I doubt it is the true cause. There are many Google Chrome Helper CPU eating up issues. Some are obviously not plug-in and extension related.
Chrome for Mac is almost useless because of this issue. I first encountered this just after Maverics release and Google has not fixed it until now. Very odd.
Issue 373923 - chromium - Google Chrome Helper Process Taking up >100% CPU on Macs
> Both Unity and Unreal have their engines running well
Running well? You'll know there are still tough problems next year. No one download 100 MB or 200 MB scripts and assets to play a game. In the past, all such resource rich Flash or Unity Web Player games have failed. No exception.
The relief is Mozilla people actually know this problem (I talked with them at GDC).
AAA games are just too rich to "browse" on the web. People close their browser windows within several seconds. Typical home internet bandwidth is narrower than Blu-ray or DVD-ROM, even in advanced countries. Furthermore, browser cache can't handle big resources. You won't even gain server costs.
Have you played a flash game lately? The initial program begins running really quickly, where it then downloads assets using a separate loader while a splash screen displays. Sony also ran into this problem with the massive files (20 - 40 GB) for their disc-based games that are also available for download, but somehow (in many cases) the games can be played while the download is happening, as the most critical parts are downloaded first.
Browser gaming may or may not take off, but I really don't see asset-size being the rope with which it hangs itself.
I think Unity can distribute their runtime library via CDN (just like three.min.js or something). It will able to cut down the initial some megabytes.
Progressive downloading technique (like AssetBundle) is a must for both loading time and server costs. Every developer should use it because if many games have massive long loading time (like Epic Citadel or BananaBread or Monster Madness. Whatever Mozilla says, these demos are not commercial ready), end-users will hesitate to click game links. I feel many gamers already stopped considering the web as a game platform these days. Kids know how to download games from App Store, but they don't know how to use Mobile Safari. All App Store, Google Play and Steam are growing. Many users will continue to prefer download apps for a long time.
Ultimately, time may solve the problem. The internet bandwidth is growing 50% per year. Many PC browser games will start instantly 5 or 10 years later, Mobile will have more trouble.
I've experienced countless hotlinkings, rippings, clones, insults, DoS attacks and cybersquattings as a former Flash game developer. Luckily, I have not been involved in any trademark issues, but it is happening also on the web, isn't it?
False. Many (120000+) Flash apps are actively running with Adobe AIR on App Store and Google Play. AIR is a technology to package SWF as a native app.
> 4. The tools are out there. Check out appcelerator or unity's tools.
Unity can not export for HTML5 yet. Apparently they are working on it but I don't think it's that easy (As for the original article, I DO MIND the initial load time. That will be a big problem for Unity as well).
> 5. Flash never had the native performance or hardware acceleration that modern JavaScript has.
Please don't denounce Flash without a knowledge of Flash. I'm already not a user of Flash and currently developing with Unity and Cocos2d-x instead, but I feel I need to advocate Adobe guys from unfair bashing.
Indeed. Every trial to replace "standards" is called "evil". From this perspective, the web platform is far from open. The result is we all are in a local optimum trap. I already gave up expecting cool future and decided to stick to the native development for a while (for a decade or more).
BTW, as a game developer, it would be nice if this rendering latency issue will be fixed soon.
> Native will always fundamentally beat non-native, that's a plain fact.
The problem of WebGL is simply it has very low penetration. By my research, currently only 35% of desktop users can use WebGL with GPU acceleration (FYI, Flash 10: 95%, Flash 11: 75%; Flash 11(Stage3D with GPU): 70%). Now that IE11 is supporting WebGL, this might be a matter of time. However I foresee it would take 5 years or so to achieve 80%.
And, note that WebGL only has functions of OpenGL ES 2.0. Currently WebGL2, which has functions of OpenGL ES 3.0 is being developed. On the other hand, native games already utilize OpenGL 4.x. What API is used in native games when WebGL2 becomes popular? I imagine raster-based rendering might be obsolete at that time.
And I think people already know the web can't handle Oculus Rift, probably one of the most interesting, innovative and fun gadget in this decade. Of course you can use it on browsers with a NPAPI plugin. Oh, hey, the web people said plugin is obsolete and evil! Don't use plugins!!! Don't play with Oculus Rift, you, PLEASE!!!
I admit the web platform has some value on some points, but if people think HTML5 is the (only or most) cutting-edge and innovative technology, that's not correct. Absolutely not.
* if people think HTML5 is the (only or most) cutting-edge and innovative technology, that's not correct. Absolutely not.*
I don't think anyone could argue that - the web is a messy consensus, and definitely doesn't include cutting edge, innovative tech (except perhaps server-side if you want). That's not its strong point but I think the other points in its favour do make up for it.
Re WebGL, I suspect if we see killer app(s) come out using it, penetration will spread quickly and it will be kept up to date by browser makers. At present it's a bit of a chicken and egg situation.
I still completely disagree making the web an application platform. Because of the absurd HTML5 cult, many websites are obtaining unpredictable and inconsistent behavior. The difficulty of explaining it to my old parents is increasing day by day. Moreover, browsers are getting fatter unlimitedly and only a few vendors can survive and develop them. It gives browser vendors special privileges. As we are experiencing now, no one can stop this "Disable JavaScript" removing. How can people say this is "open" movement? The good old web is dying.
The web should be words and documents first (I think this page is worth reading http://justinjackson.ca/words.html). It's too late to say but if you want a sandboxed application platform, develop it out of the web. I still believe the plug-in was not a that bad idea, not the best idea though. At least you can disable it anytime and you have freedom of choice.
I suspect that the back button will be eliminated next. Because it collapses most web applications and "user experience".
If the web want to become a perfect application platform, all virtue of the web will be lost.
Good old web? What's that? The one with dancing baby gif? Or the old ARPANet?
Web has always been about managing documents in one way or the other. Now those documents are interactive and interesting to watch and listen.
I mean, if my old chem book had cool animations I could tinker with I'd probably be having fun with it right now. I don't understand the outcry for GOW. It's still around and you can still make those sites, but they are usually hard to read (no fancy column layout to make it easy on the eyes) and you have to be a great writer to really engage the audience.
Going back to GOW won't make bad writters instantly better. No more than returning to 8-bit graphic won't instantly make all games better.
FYI, current mobile browser caches are very weak and unreliable. For instance, iOS clears all cached data just by exiting Safari. Android is also in a similar situation (unpredictable and can't explain).
I guess it is caused by the storage limitations. We can't rely on the mobile browser cache, at least for now.
> Emscripten builds taking between 10 and 50 times longer to compile than the native code ones.
Hey, this is fatal. With this massively long iteration time, you can't run actual big projects. Only executing 1,000,000 lines of C++ code is not enough. We care the build time as well as the perforamnce.
BTW, have you heard that the next Haswell processors can get only 5% performance improvement? We should assume that we have no free lunch anymore. One of the UNIX philosophies is already broken.
I thought the Haswell CPU was more about reducing power usage then adding performance? I'd be curious to know how much effort was spent on the power consumption vs performance.
Intel is getting their lunch handed to them by ARM. People value power consumption over performance these days, so why would they continue pumping out faster chips?
> BTW, have you heard that the next Haswell processors can get only 5% performance improvement?
Bollocks - using the new gather AVX instructions, I've seen close to a 40% increase over IB on some floating-point code I've hand-written with intrinsics.
Existing C++ code is around 13-16% faster thanks to better cache bandwidth and a huge L4 cache. Turn on FMA (fused multiply–add) optimisation and that goes to ~20% faster.
Chrome for Mac is almost useless because of this issue. I first encountered this just after Maverics release and Google has not fixed it until now. Very odd.
Issue 373923 - chromium - Google Chrome Helper Process Taking up >100% CPU on Macs
https://code.google.com/p/chromium/issues/detail?id=373923
Issue 397642 - chromium - Google Chrome Helper (not responding) on Yosemite Beta 1
https://code.google.com/p/chromium/issues/detail?id=397642
Issue 399960 - chromium - Video playback, CSS transitions, and other GPU operations drastically heat up 13" Retina Macbook Pros
https://code.google.com/p/chromium/issues/detail?id=399960
Issue 367593 - chromium - Multiple Google Chrome Helpers are spawning and slowing severely slowing down my browser
https://code.google.com/p/chromium/issues/detail?id=367593
Google Chrome Helper using far too much CPU power - Google Group
https://productforums.google.com/forum/#!topic/chrome/LfBqIl...