I discovered I had a problem when I checked one of my uploaded three.js projects. At first I thought maybe I had done something wrong. My project used r63, so I updated to r65, but that didn't solve the problem, even after clearing the cache and refreshing. I then checked a couple of the demos from the three.js site, and I found they are slow for me, too. As an example, http://carvisualizer.plus360degrees.com/threejs/ autorotates incredibly slowly in Chrome, but at normal speed in Firefox and IE 11. I also tried http://helloracer.com/webgl/ which is fine in Firefox but really choppy in Chrome. It's a disaster in IE11, by the way, but it's an older demo. My project uses OrbitControls, with autorotate enabled. The model is a 16MB JSON file (200,000 triangles), but it worked fine before and works fine in Firefox and IE11. I'm on a Windows 7 machine with a GTX Titan (work computer). Thanks!
type chrome://flags in chrome address bar, and look for settings #ignore-gpu-blacklist
this happened to me, suddenly my gpu was added to blacklist and chrome reverted to software rendering..
For me running google-chrome on linux I needed to enable Use hardware acceleration when available in chrome://settings
Related
I am working on a mobile website at the moment and I refreshed the page, Chrome quit unexpectedly, and since then all touch screen emulation is absent and/or failing.
Chrome Version: 36.0.1985.125 m,
OS: Windows 7 Ultimate SP1
Google Chrome suddenly and unexpectedly stopped emulating devices properly. All touch screen functionality has been disabled and apparently removed. When I emulate a device, the Sensors box fails to be checked and upon inspection, does not show any 'Emulate Touch Screen' option.
I have tried the following, all in conjunction:
Uninstalling/Reinstalling Chrome and deleting all personal settings, including uninstalling all extensions, restoring all defaults, etc.
Restarting the computer
Running anti-virus software
EDIT: Installed Chrome Canary which produced the exact same problem
Please let me know if there are any other relevant details that I might need to add.
Sorry about this. We overhauled the touch emulation in Chrome 36 to be much more accurate (sharing code with what really happens in Chrome Android): https://plus.sandbox.google.com/+RickByers/posts/CBCmhVttj5C. In the process we ended up disabling touch emulation when real touch support was present (at the time we thought this was no big deal because if you've got a real touchscreen why would you want to fake one with mouse?). But some Windows PCs report that they have a touchscreen when in fact they don't really (Eg. Visual Studio installs a touch screen emulator I believe).
We're fixing this at http://crbug.com/395531 - hopefully there will be a Chrome Canary build soon that re-enables touch emulation in these cases.
In the meantime you can mostly work around the issue by disabling Chrome's support for built-in touchscreens at chrome://flags/#touch-events. Make sure you set this back to 'Enabled' after Chrome is updated to fix the issue. With this disabled, some minor aspects of touch emulation (eg. DOM0 ontouchstart= handlers) will not work properly.
Stop the "Tablet PC Input Service" and restart chrome. If chrome thinks you have a touch screen, it won't let you emulate one.
I stumbled across the answer here:
https://github.com/Modernizr/Modernizr/issues/880
I'm a bit confused because my project worked yesterday but seems to no longer work correctly today. (Yes, I've checked previous versions from git.)
The problem: Some divs previously hidden with -webkit-backface-visibility: hidden; magically appeared.
I have isolated this issue into a fiddle:
http://jsfiddle.net/Js6cg/1/
The div is visible in Chrome at 23.0.1271.64 m (wrong) but hidden in 25.0.1326.0 canary (as I expected).
Can you confirm that this is indeed a bug in Chrome or am I using the CSS incorrectly somehow?
(I've updated my GPU drivers (AMD Catalyst) from 12.8 to 12.10 today, if that's important.)
Additionally, the site that demonstrates the effect I've been reproducing appears to work +- correctly at Chrome stable (except for aparrently ignoring -webkit-perspective and animating kind of choppy), while Chrome canary renders it very well and accepts the perspective. I'm confused.
OK, that is embarassing.
The story looks like: I've updated the GPU drivers but looks like I haven't actually restarted Chrome for ages. For some reason, it was unable to re-enable GPU compositing after the driver update and hence some more advanced CSS3 effects (like perspective and backface-visibility) didn't work at all, while simple transforms used a fallback CPU implementation, which also made them look choppy and on the demo site.
I've started Chrome Canary well after the driver update, so it didn't have any issues with GPU compositing. One instance worked, another didn't, but version mismatch wasn't important here at all.
Restarting Chrome fixed that issue. And I'm taking a break!
I'm trying to understand these strange rendering error boxes that are too big to be ignored. This seems to happen on Chrome in Windows 7 (my testing isn't too elaborate) and nowhere else. When I attempt to inspect, they all disappear. This could be some kind of video card issue as I'm using some pretty advanced CSS3 transitions that could mess up memory. In any case, if someone could offer advice on what I could do to fix, I'm at a loss. The site is www.crane-usa.com
Having the same issue with our site using 21.0.1180.89 and 21.0.1180.79. Problem is in Windows 7, Mac OS X latest, Ubuntu and in Chrome frame running in IE9. IE9 with Chrome frame disabled works fine. The problems are intermittent and unrepeatable. Inspect element removes the problem as you say. I tried disabling GPU compositing via chrome://flags but that didn't fix the issue.
We and our users have only been seeing these issues since approx Aug 27, 2012, 3 days ago. I took a look in crbugs.com and found that this seems to have existed for a couple of weeks already. http://code.google.com/p/chromium/issues/detail?id=143647
Sorry our site is not public so I can't post our url but you're not alone.
I'm not really sure what is causing this but in the current stable version of safari on OSX 10.7.X I'm only seeing 3-4 frames rendered. I downloaded the lastest safari beta and it seems like they improved it, but its still dropping a large amount of frames.
Here is an demo that should be viewed in Safari on Lion:
http://jsfiddle.net/JEKAh/1/
Please respond if you know why or what is going on
edit: still is a problem on mountain lion
It turns out that this bug is related to the transfer encoding of the video files. If you are sending the video with Content-Ranges you will see this issue in safari. But if you send the video using Transfer-Encoding: chunked... it will work fine
I used a simple node server to test this: https://gist.github.com/3746561/c303f84866542c4a6ec2956ecf158cb9f492a7a2
-- edit
the above is only a fix for Lion, it appears that Safari Mountain Lion is unable to render frames from a video that is sent using a chunked transfer encoding, a side affect of this is also massive safari memory leaks... I ran a video being piped for canvas for 2 mins and the Safari Web Content process shot up to 12GB of real mem used. -_-
-- edit
after additional research i have found the original issue with standard video to canvas in a recent nightly webkit 537.3 and have confirmed that currently in webkit 537.11 these issues no longer exist... so all i can do is hope that apple updates safari soon including the webkit fixes
-- edit
this is now fixed in OSX 10.9 :)
Firstly, I acknowledge that this might not be the answer you are looking for but it's something which I've just been dealing with for a client so I thought I'd throw it up here:
They reported that their site "Was no longer working well and the animation was jumpy".. (hmm..) Their site uses canvas rendered videos with some overlays for a lot of the visual elements.
So after a while we determined that they had just updated their MacBook Pro to Lion and now their site was slower and less responsive. I was a bit baffled so I got them to bring it to me. To cut to the chase:
Lion & Mountain Lion require a tonne more physical memory (RAM) than Snow Leopard did (due to the new VM architecture as I understand it), I compared their site playback to another MBP with a lower spec, with SL installed and the SL version ran smoother.
After a bit of reading on the Apple support forums which suggested adding RAM, it was all fine again, in fact it seemed smoother than ever..
Not really a programatical answer but one which I thought may be relevant..
I have a Linux box. How do I see how my HTML pages look as rendered in Microsoft Internet Explorer? How do I test JavaScript functionality in Internet Explorer?
I don't want to install a VM and a copy of the Windows OS.
Your best friend as a Linux web developer is IEs4Linux, which uses Wine to run different versions of Internet Explorer.
Check out this page to see how your page will look across browsers and OS'
http://browsershots.org/
To actually interact with your web site though I would suggest something like Wine or a VM like Xen.
Also see this link: How to install internet explorer on Ubuntu or see this page IEs4Linux.
I use Linux at work and do web development that has to support Internet Explorer 6 (and later) and Firefox 2 (and later).
IE4Linux is not really good enough for properly testing Internet Explorer browser rendering as it doesn't work exactly as Internet Explorer does in Windows. You could use something like browsershots, but I would recommend running Windows in a VM and test using that for Internet Explorer testing. I've done that for awhile and it works great as long as you have a spare 512 MB RAM for Windows XP.
Another service similiar to browsershots, but faster, is IE NetRenderer. Otherwise, if you have a copy of Windows lying around, why not use a virtual machine? Suns VirtualBox is nice enough.
Probably your best bet for accurate rendering without paying for a Windows license is using one of the MS provided virtual machines. Below are some links on tutorials for setting up the VMs using VirtualBox.
http://blog.philipbrown.id.au/2009/03/internet-explorer-application-compatibility-vpc-images-under-virtualbox/
http://www.makeuseof.com/tag/installing-windows-7-on-a-virtual-machine/
I've used VirtualBox and these images quite a bit and it works well, the only downside is you have to reinstall every quarter because the images expire.
I agree that browsershots.org is a great place to start, but it only provides a screenshot. If you're using JavaScript or jQuery and need to see how see how things appear when you interact with your page in Internet Explorer (practically any version from Internet Explorer 5 and up), crossbrowsertesting.com is an excellent resource.