After upgrading to Chrome 18 on OSX 10.7.3, we started noticing fleeting rendering artifacts seemingly related to form elements:
They come and go during scrolling, it seems. I've been testing in a variety of other OS/Browser environments and have been unable to reproduce this, nor had it happened in previous versions of Chrome.
This is a mature, stable web app with fairly complicated HTML/CSS. I haven't been able to produce a simple test fiddle that reproduces this.
Anyone else seeing issues? Can you think of a possible HTML/CSS cause and not a Chrome bug?
I also noticed that Chrome 18 displays artifacts in some pages, but this only happens when that page is GPU accelerated. I asked a similar question a few days ago:
GPU acceleration crashes website
Chrome enables the hardware acceleration when it detects 3D transforms in your CSS.
You can go to chrome://flags and enable the "Composited render layer borders" option, if you see green squares all around your page thats because some CSS rule is causing your page to be hardware accelerated. You can try removing any 3D CSS rules or assign a higher z-index to these elements. It usually helps.
Related
For the flickering issue on iPhone when using Transition CSS, for example this link: iPhone WebKit CSS animations cause flicker
My question is what exactly "-webkit-transform:translate3d(0,0,0);}" does conceptually that solves this issue?
The declaration -webkit-transform:translate3d(0,0,0);} activates hardware acceleration: iOS uses its GPU instead of CPU and the result is way smoother.
Translating by 0 pixel in 3 directions doesn't change anything to the position of your pixels so it's safe, except if it overrides an existing transform.
EDIT: it's been one way of activating GPU for a few years now but - broadening your question - it's not the only one and Chrome is changing or has changed its compositing/layer system. I didn't follow thoroughly these changes or new ways of activating it but you'll learn a lot by viewing demos on YT by Paul Irish, the Chromium blog, Google Devs or html5rocks
This is an HTML 5 Canvas application. It's a pretty standard "designer" application where the user adds objects to a layout, moves them around, and edits their properties.
It works very well, but it turns out to have real performance problems in IE 9 on Windows 7. I would appreciate any thoughts!
Operations often take 10 seconds instead of the usual 2 seconds.
Also, after using the application a little while, the browser gives an error message that the host "is not responding", giving options Recover Webpage and X. Once that starts to happen, it happens for every user action including the File menu, and I can only get out of it by editing the URL location text. In particular, it generally happens on any attempt to use the browser's profiler in Developer Tools. This is obviously frustrating, but it may also be a clue. I wondered if there might be pending synchronous AJAX calls, as suggested by this error message, but capturing the network traffic using Developer Tools suggests that all calls are complete.
The problem seems specific to this combination of browser and OS. IE 9 on Windows Server 2008 behaves OK, and so do Firefox and Chrome on Windows 7. The problem is the same for 32-bit or 64-bit IE.
Most of these operations have a server-side component too. For example, adding a text object makes an AJAX call to serve an image for the object. The server API is implemented as a small TurboGears application which uses ImageMagick for the image processing. But rough profiling indicates that nothing unusual is happening on the server side. This suggests that the problem really is in the JavaScript.
The Task Manager shows the browser using CPU of 90% or more when the application is running. This is true for any browser, not just IE 9. This is likely because of the tight rendering loop in the application, so one idea we had was to redraw the canvas less often. Unfortunately this did not seem to help. requestAnimationFrame seems like a good idea, but is not supported in IE 9.
A colleague suggested that using the Google Chrome Frame plug-in might help. It might be an acceptable solution, but I haven't tried it yet.
I found some advice to turn on the Control Panel option "Use software rendering instead of GPU rendering", but that doesn't seem to help.
One thing I have noticed: It seems the canvas is much slower in IE if you start drawing on it when it's not in the document.
So I do document.body.appendChild(canvasEl) before I draw. You can even make the canvas element dislay: none; but at least it should be in the body.
Update: It seems that for Chrome and Firefox, appending the canvas to the body is slower. So if you don't need it to be added to the body, don't add it for Chrome and Firefox.
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.
Just updated Chrome to 18.0.1025.142 from 17 on a Mac running 10.7.1 and it's killed the performance of our site. We've been using translate3d where available to move a large number of items around the screen. I'm animating with requestAnimationFrame. In 17 we were getting framerates upwards of 50fps. Now lucky to get 15fps. It's really bad.
Has hardware acceleration been turned off by default? Anyone else noticed any problems like this? I've noticed the font rendering has been improved and is now on a par with Safari (which runs the site beautifully) maybe this change has had an effect on general rendering performance?
I'm afraid I can't share the link due to an NDA. But any help would be greatly appreciated!
Update:
As far as I can tell it IS still GPU accelerated but the performance is really bad, other people have reported similar things. The Chromium builds of v19 seem to be back to the old quality of performance.
There used to be a flag when launching chrome --show-composited-layer-borders which would put red borders around gpu accelerated elements. This option now seems to have been added to chrome://flags/ but it paints green borders around layers and doesn't seem to distinguish gpu elements any more. Does anyone know of an option to show if elements are being rendered by the gpu?
chrome://gpu/ says that everything is being hardware accelerated...
Reproduce the problem with fresh code in a new web page. This will greatly help both your SO question and bug report.
Browsers regularly tweak whether hardware acceleration is used based on whether your graphics card and driver version is supported. Updating your graphics card driver may fix the problem for you, but maybe not everyone else. (This tool I wrote might help: graphics driver updater)
In fact it's a bad idea for your website to depend on hardware acceleration, because a significant fraction of users have crappy unsupported hardware and/or out of date drivers which are blacklisted to stop the user's computer crashing while they browse the web. They'll get crappy, un-accelerated framerates too, in any version of Chrome.
So IMO the real problem is your website depends on hardware acceleration which not everyone has, and you just noticed because Google blacklisted your setup in Chrome 18.
I'm working on a page turn animation. The performance is disappointing. Particularly if you take the pages class and make it something like 800px wide (paste $('.pages').css({width: '960px', height: '600px'}); into your console). I used to have around 16 transitions running at once and reduced it to 9, many of which are transforms! I don't know what else I can do.
Chrome does not seem to be using the GPU. It spikes the FPS on initial page turn but then dips down at regular intervals (enabled this with about:flags):
Try it out in Safari and you will get better performance but see that the animations do not sync up, often lag behind each other, and there's a weird wobblyness that Román Cortés's project also suffered from in the same browser (I haven't made it work in Fx yet).
There hasn't been much good material about how to optimize CSS transitions and animations on the web and I've been mostly teaching myself. I was hoping someone would have this kind of advice.
In order to take advantage of the GPU you have to use translate3d(x,y,z) instead of translate(x,y) in your -webkit-tranform's. This will force Chrome to use the GPU to render the animations.
Beware that while the performance will greatly increase if the computer has a good video card, it will also degrade on a slower hardware.
Here's a page flip I did for our launch of Sencha Animator. It's also inspired by Ramon Cortes' original, but uses different mechanisms - as far I as remember. It's super smooth in Safari and on iOS, but kind of jerky on Chrome desktop. Haven't checked it in Android 4 yet though.
I'm using Chrome 17 on OSX, and it seems fine - runs at around 20-30fps, no dipping or graphical issues. I suspect that this is just an issue with older Chrome builds.
Animating box-shadows and -webkit-gradients is very expensive, try removing them temporarily to see if it improves performance. If it does, see what you can do to replace them with images.