I've been working on an HTML5 game for close to a year now, and the newest version of Chrome (49) has completely wrecked its performance. The game that was easily running at 60FPS now struggles to get over 5-10 after updating Chrome. I've verified that it is the Chrome update using a stable version of the game and updating Chrome on my gaming PC, to see the same drop in performance.
I figured there would be something on the web or from Google about this by now, has anyone else seen this hit in performance? Is anyone aware of what has changed in Chrome that may have caused this issue?
I did notice performance issues when calling drawImage() (about 10k sprites). The issue seems to be fixed in chrome 53, so I think it was a performance regression.
Related
I've been working on a VR game within A-Frame. When I started testing on devices (iPhone 7/iPhone 7 Plus running Safari, and Samsung Galaxy S6 running Chrome), I began to notice the page would randomly refresh, which is an issue for us, as it restarts the game.
This is happening with the demos on their website, as well as our self-hosted game.
Has anyone experienced this issue, and/or know what the issue or the solution is?
I have been experiencing memory issues multiple times, when using iOS systems, rarely on androids.
My issues were related to memory leaks, or high memory usage causing my site to crash.It was happening mostly, when i tried loading a highRes photo on click, and apparently stuff in <a-assets> is cached partially, so Your site does not load for a day, but it uses up way to much resources when loading stuff from there dynamically. My solution, as i had little time to further investigate this issue, was loading all assets on the scene, either somewhere You can't see them, or making them invisible by setting visible to false. When switching visible-not visible, I didn't have so much memory issues, so phones could handle it, but it took longer to load.
a-frame had issues with performance on mobile before, and I found this guy had the same issues as me. It's working way better, then when those posts are from ( 2016 ), but i still have problems, solved by such workarounds. I hope this could solve Your problem.
I'm having a issue which is hard to debug. I'm using a Javascript library (the JQuery Flexslider plugin) in a number of different places on my site. It's all working fine except for one particular phone where it doesn't work and slows down everything on the page.
So far, I've only seen it happen on this one device. Other devices of the same type do not have the issue. This person has an iOS that's a few versions out of date and not much memory, so I think it's a memory issue.
An old hack was to move the carousel element that has the issue on the page with Javascript, but I want to find and fix the root issue.
How can I start debugging this? I'm not sure how to test for a memory issue on a device.
If you're on a Mac, then you can plug in and use remote debugging via Safari, where you'll have access to the tools, including the profiler (not sure the state of Safari support in Windows). There are numerous resources for showing how to remotely debug a device, unless it is a really old version of iOS you should be fine, you’ll have to enable the develop menu via settings but after that its plain sailing if you know your debugging tools.
I'd agree that it doesnt really sound like a memory issue, although jQuery tends to be hungry in that respect, I dont know the plugin in question but the quality of plugins is hugely variable in jQuery-land. Old phones and old versions of jQuery certainly never played well together.
When you say one phone, you mean one type of phone + iOS version? The question isnt clear, its almost reads like you have 2 identical phones/os's where 1 works and 1 does not.
If you use Chrome you can use the Heap profiler
First open your developer tool and start recording.
Next start using your page and try to replicate your issue, stop recording and review the stats.
This is likely not a memory issue, but a cpu issue. The way jQuery does animation is processor constrained on older dvices. Factors that are easiest to handle include:
size of the page (html length and complexity)
animation steps, length, and complexity
You have a couple of options here, but the simple answer is you are asking too much of the older processor. Assuming you are using this plugin http://www.woothemes.com/flexslider/ you could try disabling or simplifying some of the transition effects. animation and animationSpeed would be the first I would suggest.
If you are interested in not changing the experience for most users you could consider tying into the start and end functions on the callback api and checking the time it took to perform the first transition, then reinitialize a simpler version of the slideshow for that device.
The hard thing here is there isn't really a right answer. If one of the above options doesn't fix it you're likely looking at choosing/building a different slideshow, degrading the experience for everyone, or determining the best way you feel comfortable with choosing who gets the degraded experience.
I'm working on a project via arcgis javascript api.
With hundreds of graphics drawn on a graphicsLayer, it works well on chrome or IE11, but on IE8 and supposedly also IE6 when I drag the map, it's extremely slow so that makes it completely unusable.
I found the "displayOnPan" option of graphicslayer which seems to be designed specifically for IE. But if I turn that off, the performance is still unsatisfactory, besides, the disappearing and reappearing of the graphics each time the map is panned are really irritating.
No question of requiring the users to update or change the browser.
Is there any ways to the problem?
According to ESRI, no. This is what I got from ESRI's support centre when I put the same question to them
Hi Clark,
The Javascript API support for Internet Explorer 9 introduced significant performance improvements for drawing graphics.
In earlier versions of Internet Explorer, drawing large number of graphics performed poorly compared to browsers like Firefox and Chrome. At IE9, graphics drawing performance is much improved over earlier versions of IE and is comparable to other browsers.
A table comparing performance between the different browsers is available at https://developers.arcgis.com/javascript/jshelp/new_v23.html
Feature services are essentially graphics. If the layer(s) you're loading contain a large number of features, this is the reason for slow performance in IE8.
Can anyone explain why the provided canvas animation stutters? I've created a test stub which demonstrates the problem.
I see the stutter in FF, Chrome, IE on desktop and in FF and Chrome on Android.
Is the stutter due to garbage collection? It seems even raf generates a double on each call which eventually requires gc. If gc is the cause then html5 animation is pretty much doa. Sigh.
The same question was asked a year ago but because I'm a new member I'm not able to contact the author to find out his solution. HTML5 Canvas DrawImage Stutter / Choppiness . It is really too bad there is no way for a new user to get another user's attention, since the author of that other question may have the information I'm looking for, an simply hasn't posted it. I tried posting to his question in an effort to get his attention, but my post there was deleted as a rules violation(which is was). Guess I'm out of options. Chicken and egg problem with rep.
Ok, so after pulling my hair out for 1.5 days I think I have an answer. It appears browsers vsynch to a monitor, which I guess is the point of calling requestAnimationFrame. It appears the synch mechanism can get confused when running on a multi monitor system. I have three monitors. When I disconnect all but one monitor and restart the browser, the problem appears to go away. This kind of makes sense given that the problem manifests sporadically, ie I'm guessing when a given monitor gets out of synch with which ever monitor is providing vsynch to the browser.
Since I'm not certain about this I'm hoping others can confirm or shoot down my theory. I'll continue to (re)test with different monitor configurations, but it would be nice to get confirmation from another brain and set of eyes.
Edit 01: I'm not completely nuts. http://news.softpedia.com/news/Firefox-Nightly-Adds-Support-for-Vsync-for-Smooth-Animations-360245.shtml
Edit 02: Some chrome users/devs has discovered this or a related problem. Finally something might be done with this issue. See https://code.google.com/p/chromium/issues/detail?id=422000. BTW, IE11+ does not have this issue. Started using IE11 for baseline testing, since chrome is having QA issues lately.
Edit 03: Just ran across this q&a which is similar. Good info in the first answer. Chrome requestAnimationFrame issues
Other than just sniffing browsers and telling anyone not using Chrome tough luck on purpose (75%+ of the internet?), I'm looking for different options to make an executable out of a canvas game, if that's even possible.
The idea is to control the performance of my game by including v8 to users who don't have chrome installed.....is there a way to interface with it?? Something like a web "wrapper" like Flash's plugin so you could install a v8 "plugin" cross browser???
The canvas game works with safari and firefox, but at 50-60% of the performance experienced in google chrome.
Another discrepancy is with Firefox if I make the game map more than 100x100 tiles, it chokes when generating the map and gives a "stop script" popup, if you hit "continue" it throws another popup for "out of memory, close your stuff to prevent data loss".
Using the same code in Chrome or safari, I tested maps with 500x500 tiles (yes that is 250,000 tiles, where firefox choked on 10,000 tiles....) which runs smoothly/consistently in both Chrome and Safari, though safari is 60% of the frame rate chrome manages.
I haven't yet found a limit to what chrome can handle, and using culling to only draw tiles around the view it's the same frame rate with 250,000 tiles as it was with 100 tiles (more than 200fps in chrome with 250k tiles!!!!! small view though), the only thing that changes performance is the size of the canvas element/view. Meanwhile Firefox can't even calculate the zones, let alone draw all the tiles inside the proper zones. (it does work over 100fps with maps 10k tiles or less)
It's tempting to allow anyone with a browser that supports html5 to play the game, but at the same time, user's opinion of your game will be MUCH MUCH MUCH better if the PERFORMANCE IS TWICE AS GOOD as the crappiest version that "can" play your game.
I'm reading about V8, and how you can incorporate it into your own c++ applications, or run it standalone?? Has anyone developed a wrapper to make a self contained executable for html5 canvas games?? Or a web wrapper to embed an interface to V8 or something???
I just installed chrome myself this week, after trying to target as many browsers as I could in the past, and it changed the way I think, now it's just not as good once you've had over 200fps to then play the same game with under 100fps..............And as much as I've thought it was idiotic to require chrome (seen lots of html5 devs begging people to use chrome) I've come to the realization I was ignorant, and now I think the only way to enforce the full potential of my efforts is to drop coverage for all browsers except ones that can output a set level of performance.
Otherwise the only thing I can figure is to make a different version of whatever games I develop for firefox with a smaller viewable window, smaller map, etc, then on other browsers, check performance and scale the view/map size based off what browser they're using.
Another temporary idea I was thinking of, if a user has google chrome, the game window will be 700x500px on the screen, if they have safari, drop it to like 500x375px to achieve the same frame rate, and if they have firefox the window will be like 400x300px.
At the same time, if a user is playing the game with Firefox, in the 400x300px window, I would include an obvious(blinking? lol) border around the window 700x500px showing how big the game window would be if they were using chrome? Does that sound like motivation? Then they can get a taste of the game, if they like it they might find it worthwhile to install chrome to view the full size game????
For IE<9, you can do what you're after with Google Chrome Frame. This works like a Flash-style plugin, which you can prompt users to install. It isn't available for Firefox or Safari, as far as I know.
While I'm aware of several frameworks for desktop apps using HTML and Javascript, they generally seem to use WebKit, so I would expect performance to be comparable to Safari at best (Titanium Desktop from Appcelerator is another option, but also WebKit-based).