When I run the chrome performance tool, most of the time I get a very shallow stack shown. So it's impossible to debug anything.
It doesn't happen on my work machine but does on my home machine (also on a friends machine with the same config):
Windows 10 Pro - Version 10.0.18362 Build 18362
CPU ryzen 7 3700x
Chrome Version 78.0.3904.108 / Beta / Canary
Sometimes if I use CPU throttling it shows the proper stack but the vast majority of times it does not. Am I missing a feature toggle somewhere?
Is someone else running into this?
Thank you.
Larger screenshot:
Try using chrome stable version.
Canary is simply a much newer release that's not as well tested. I have debugged this page in my chrome (version: 78) over 10 times with 6*CPU throttling. I got stack over 10,000 ms all times.
You can get more information about performance tab in this official link.
Related
Originally posted here.
I was under the impression that WebGL should work on Chrome on pretty much any desktop device, but that it may fall back to software rendering in some cases (assuming you don't pass failIfMajorPerformanceCaveat=true when getting the context). However in practice this seems not to be true for a substantial number of users on both Macs and Windows (especially, but not limited to, those within some kind of managed corporate IT system).
As far as I can tell, on all hardware/setups where WebGL is disabled in Chrome, it is possible to run it using a different browser (FF, and even IE11). I believe that IE11 only uses software and FF may be less strict with its blacklisting of GPUs, but that doesn't explain why Chrome can't switch to software when hardware is unavailable. Indeed, in some cases, overriding the GPU blacklist in Chrome does seem to work (but presumably is not a good idea).
So firstly, could I check that my assessment of the situation is correct? And secondly, could anyone suggest how to force software rendering (i.e. flags etc.) and/or point me at an issue discussing this?
Any advice would be very much appreciated - even if the process is rather involved it is still worth knowing about as it may be workable for our clients.
update:
#gman points out that there is no software emulation on Macs in Chrome, but that still leaves the question of what's going on in windows.
update 2:
(to partly answer my own question): it seems that (at least on 32bit Chrome on windows) if you go to chrome://components and see SwiftShader is at version 0.0.0, then simply hitting the update button should download the latest veriso,n and hey presto..it works. Not sure about 64bit Chrome though.
update 3:
As #Nicloas says, M59 in Chrome (to be released in May/June 2017) should fix this issue in Chrome on Windows and Linux, with Mac following later.
Quoting my own answer from swiftshader#googlegroups.com:
I'm happy to let you know that with the upcoming M59 release of Chrome, we have integrated SwiftShader to provide seamless fallback support for WebGL in case the GPU is blacklisted.
We were previously only using SwiftShader as a separately downloaded component, which indeed does not work on managed corporate systems, and required a browser restart. Integrating SwiftShader was only possible after open-sourcing it and substantially reducing its binary size.
You can test it today on Windows using Chrome Canary or the Beta channel, and specifying the --disable-gpu launch flag. Linux is also supposed to work but the libraries were mistakenly not shipped as part of the beta package, which we hope will be rectified in the next update and before it reaches the Stable channel. We haven't started integrating Mac OS X support yet, because Chrome works significantly differently there, but it's on our radar.
I'm using Mac OS Yosemite with Google Chrome. Sometimes, for some random unknown reason, Chrome takes over 1 core at 100%. When I kill the process, I notice that It killed the tab in which the Meteor app was loaded. Sometimes it takes over my 4 cpu cores.
I'm using the development mode and, at least I think, I'm not doing anything to trigger it. This behaviour seems random and very hard to reproduce. I don't if it's Chrome or Meteor that cause this random behaviour.
Did someone already experienced this?
With IE 10 testing my website on older versions of IE was very easy and always worked as it should, I just went to the developer tools, picked the version I wanted from the menu and I had no problems.
Now, after upgrading to IE 11 I encountered some problems with this method of testing. First, stuff I put inside HTML comments like <!--[if lt IE 10]> don't show anymore. Second, the same website that I tested a few days ago on older versions of IE with IE 10 looks very different when doing the same tests on IE 11.
So, why do all this stuff happen and how can I solve it?
Internet Explorer 11 shipped with a fairly good set of emulation tools. If you know what issues are being reported in Internet Explorer 10, you can attemp to replicate those in emulation. If you succeed, it's very likely that you can proceed to troubleshoot those issues while in emulation.
At times you may run into some things that aren't reproducible in emulation, and instead require a native instance of Internet Explorer 10 (or any other version for that matter). At this point you really only have a couple of options:
Virtual Machine in your browser (http://browserstack.com)
Virtual Machine on your desktop (http://modern.ie)
Each option has its own set of pros and cons. In-browser virtual machines can be spun up very quickly, and don't require a serious amount of system resources to run. That being said, the experience can be choppy and not conducive to troubleshooting issues that rely on low latency.
Desktop emulation is great because you have a more near-native feel. Unfortunately, this means you need to download very large files to get a second operating system running within your current operating system. Furthermore, you may find yourself wrestling with configurations and more.
I personally use a combination of the two, depending on what issue I am presently trying to troubleshoot. As a good practice though, writing clear and valid markup, along with using best practices like progressive-enhancement, and feature-detection to serve up alternate code-paths, results in a lower chance you'll have to spend much time debugging anything.
The latest ie11 have functionality of like previous ie browser version.
1 To access the modes, start the F12 Developer Tools,
2 click the Emulation icon at the bottom, and choose a Document Mode — they’re not named “browser modes” any longer
This article may help you.
http://www.sitepoint.com/ie11-browser-modes-return/
I had users complaining about issues in IE10, and was not able to recreate them in IE11 using F12 emulation. What I ended up doing (after many attempts to uninstall IE11, and install IE10 to no avail (in Windows 10)) was this:
Download VirtualBox here: https://www.virtualbox.org/wiki/Downloads
Go to: https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
Download the VM you want to test with and then load it into VirtualBox. There are instructions on their website on setting options etc. Mostly you need to set memory, and virtual hard disk location and size. I used 1024MB and the default for the drive, since I am only running IE with this VM. It worked great. Networking by default put the host at 10.0.2.2 so my localhost test website running on localhost:8080 was at http://10.0.2.2:8080// on the VM. It worked well.
Hope this may save someone some time.
The emulation missed two different bugs one with Array.filter, and another with __definegetter__.
The VM picked these up. It is a slower approach than emulation.
Just saw the "On IE11." Sorry about that - still this is my recommendation. And you don't have to uninstall IE11.
We have some software that uses a Chrome Extension to automate the browser (to crawl client web sites).
Usually we run several instances of this software in multiple tabs (up to 5) to parallel up work.
In Chrome 28 (beta) we have noticed that the inactive (background) tabs seems to be heavily throttled or running at a significantly lower priority. Benchmarks show that our extension is now running around 10 times slower in an inactive tab than when in the active tab. A similar behaviour is also seen in the active tab if Chrome is minimised.
This behaviour is not seen in Chrome 27 (stable) where the performance in active/inactive tabs is comparable.
Any thoughts or ideas would be greatly appreciated.
Our Chrome beta is (Version 28.0.1500.29 beta-m) running on Microsoft Windows 7 and Server 2008.
thanks
richard
On newest Chrome 55, this 'problem' (or maybe call it 'feature'?) still persists.
I've reproduced this problem on my build-page (runs lots of tests of an Ember application via QUnit) and on the background they take much longer. As #apsillers reported on a comment, this has been reported on another thread Javascript performance when running in an unfocused tab
Where i work uses Throughworks Twist 2.2 with Selenium for testing automation. For some odd reason on my particular machine the chrome driver starts but does not load chrome. The console reports no errors and i have no feedback on which to progress with. I installed Twist in the exact same way as everyone else here and it works for them. Twist will run with firefox for me but it is not as reliable as chrome and really impinges on development. The Twist site is typically useless source of information.
I'n not expecting answers but would appreciate any hints as to where i can start looking into this.
Turns, out Chrome driver was trying to launch a Chrome version installed under another user account, that was probably out of date. Delete old user profile and it works.
It would be good to find out where Chrome Driver gets this config from.