While testing an SVG animation I've run into a rendering problem in Chrome Version 23.0.1271.95.
The animated triangles seem to leave some black vertical banding.
This goes away if you tab away from the page and back or if you otherwise force a redraw.
You can find the animation test here:
http://bit.ly/HexaGridTest
And here's a screenshot:
Looking at other posts on similar issues it seems that the only way to eliminate this GPU-acceleration-related problem is to force a redraw at the end of the animation.
Someone suggested adding -webkit-backface-visibility: hidden to the SVG, but this didn't solve the issue for me.
Is there any alternative? Any flag or CSS property I could set to avoid the artifacts?
Related
First of all, let me explain what I mean by "smooth scrolling" here. When I rotate the mouse wheel by one "step", e.g. on Google Search results page, the page gradually moves up/down - the transition from the "before scroll" to "after scroll" states takes some time and is nicely animated. However, whenever I create a long page in html and try to scroll just one "step", there is no animation or transition on scroll - the page just instantly jumps few lines up or down. The average repaint time of my page takes about 5ms, with peaks up to 8ms, so I know repaint time is not the cause of that.
I know that such smooth scrolling can be achieved without any scripting, as for example the site http://www.thecssninja.com/ scrolls super-smooth on Chrome even with js disabled.
Why does Chrome choose not to scroll my page smoothly? How do I achieve smooth scroll without depending on JS, as CSS Ninja manages to?
PS Firefox does not seem to have that issue. How do I tell Chrome with my html/css that I'd like my page to scroll smoothly?
Either you can enable chrome smooth scrolling manually, which does not make sense for website development.
Or you can use some of the libraries to achieve that.
https://github.com/fatlinesofcode/jquery.smoothwheel
Sadly for chrome you cannot enable smooth scrolling through HTML, CSS or JS.
I know you're not after JS solutions, but I've never seen anything guarantee this outside of JavaScript, and karan's link above is certainly the smoothest example I've seen of doing this.
(Proviso: I'm using Chrome for Windows, not Linux. Apparently, that may make a difference.)
I use Chrome myself, and I always get the pages scrolling in jumps, not smoothly--even the pages you described as 'smooth' above step for me several lines at a time, including the Google results page. There used to be a flag available for this in Chrome, which allowed you to turn on smooth scrolling -- it could be accessed through Chrome's flags (go to chrome://flags/ to see those that are available) -- but it's now only available for the Linux Chrome platform. It may be available again in the future, but for now at least, it isn't. Hopefully, though, these experimental features will eventually find their way into Chrome, and render this whole issue obsolete.
Firefox, on the other hand, scrolls in nice smooth steps no matter what page I'm on--including my own local info pages which have almost no styling at all. IE scrolls smoothly, though not nearly as nicely as Firefox, while Opera behaves like Chrome, and steps through the pages several lines at a time.
I'm pretty sure that this is an issue to do with the browser, and not something that you can currently remedy with styling alone. Sorry I couldn't be of more help, but if you're doing this for a client, at least you'll be able to explain the issue.
I would highly recommend finding an alternate solution, but I have managed to find a solution to this exact problem for one of my websites. Akin to just using glitter glue to solve a leak in a wall, I discovered that including an iframe for a Google map on the page (even if it's hidden) somehow added in smooth scrolling. I have no idea how it works, but for some bizarre reason it does.
As I said though, I highly recommend not doing this, as its an extra (and sometimes lengthy) request made on each page to include an element most users won't ever see.
I'm working on a web page design and Chrome is wigging out when I change a stylesheet. I'm trying to switch between light and dark themes.
I have this <link> to start:
<link rel="stylesheet" href="/css/dark.css" id="theme">
To change the theme, I'm doing this:
$('#theme').attr('href', "/css/light.css");
I have code to actually toggle (loads dark if light is loaded, and vice-versa). Whenever the stylesheet of the non-default theme is loaded, it likely -- but not always -- glitches after I move my mouse around. For instance, after I first toggle the theme to the light theme:
It actually does repaint the full page with the theme for a split second, but then it turns the screen black (but it does not revert back to the dark theme, as the dark theme is not black; it actually has a dark gradient).
When I move the mouse around some more:
The white area expands in blocks over where my mouse is moved, until I move it over most of the page it goes back to what I expect. Or, I can resize the window and Chrome fully repaints the page as expected.
Removing the fancy tooltip doesn't fix the problem:
I've tried invoking a window resize event. I've tried using jQuery to show/hide the html and body tags to try to trigger a repaint. I've also tried deleting the theme's <link> tag entirely and adding a whole new one to the DOM. Alas, I see the same effect.
Firefox and Safari don't behave this way. But I absolutely have to get this working on Chrome. Any ideas?
Update (March 2014): This page is part of the web UI of GoConvey. It still renders fine in Firefox, and the glitching in Chrome at this point is less frequent and slightly different in its nature, but it's still there. Anyone is welcome to take a look if you are feeling generous.
Wow. Here's the CSS hack to fix it:
-webkit-transform: translate3d(0, 0, 0);
This forces Chrome to use the GPU to render the element. I no longer see the glitching.
Update about a month later: Okay, well, I've continued to develop this web app and now the glitching is back. Still trying to work around it. Now sometimes the whole viewport goes blank and I have to resize the Chrome window in order to get it to re-appear.
If anyone would like to try this and see the glitch live, the page is GoConvey's web UI (Chrome on Mac).
I'm not a web developer, but I was dabbling with 3D CSS transformations and animations and found that they didn't interact with :hover the way I hoped or expected. I wasn't able to readily find any disclaimer that this is a known problem, so I'm wondering if I'm just doing something wrong.
To reproduce the problem simply, start from this demo 3D cube animation here:
http://cssdeck.com/labs/simple-css3-3d-cube
Add this to the bottom of the style section:
#cube div:hover {
background-color: white;
}
I'm looking at that, using Chrome. I was hoping that, as both the cube rotated and the cursor moved (or didn't) the front-facing side containing the cursor would have a white background. But in practice that doesn't happen properly. If I scroll the cursor over the animation it picks out the correct panel to highlight but then it often fails to update when it should. Most noticeably, if I stop moving the mouse it doesn't seem to detect any change in what element the cursor might be hovering over.
Is this a known shortcoming? Does anyone have a solution?
It appears there's a difference in Chrome's Webkit engine vs Firefox's Gecko engine. Firefox continually runs to check a hover status, while Chrome does not.
I tested it in Chrome and Safari (both run Webkit) and they have similar results. They do not update the hover state if you keep the mouse still. Firefox, on the other hand, continually checks the hover area when the mouse remains in the same place.
I'm developing a website and whenever I load a pretty long page on chrome, it creates some sort of a box that covers up the bottom portion of my page. The long pages look fine on Safari and Firefox; it's only Chrome that is causing this problem.
Here's what the behavior looks like:
And here's the page with the issue: https://nosh-staging.herokuapp.com/events
If you keep scrolling to the bottom, you'll notice the giant white box that covers the last 15% - 20% of the page.
Few quirks I've noticed:
I'm using a 15" MBP (1440 x 900 resolution screen) and a 27" Thunderbolt display (2560 x 1440). When I open up Chrome in the Thunderbolt display, the page loads just fine. As soon as I move the window to my 15" screen, it just covers up the whole bottom part of the page.
When I inspect the elements, all the codes seem to load just fine. It almost feels like Chrome is putting up a huge box on top of the page. When I try to click + drag to select text, I can't see the selection because of the box.
I'm currently developing on Rails 3.2.13 and Ruby 2.0.0. Tested the pages on Chrome ver. 30.0.1599.101, Firefox ver. 25.0, and Safari 7.0. I've tried disabling all the extensions and loading the page, but that did not help either.
I was experiencing the same issue - long pages cut off half way only in Chrome. Other answers here didn't work, but changing my css animations slightly on the element that was cut off did. I removed the forwards below, and the issue stopped. Bizarre.
Changed from:
animation: 0.2s fadeIn forwards 1 ease;
To:
animation: 0.2s fadeIn 1 ease;
I had a very similar problem with the bottom of the page being cut off in Chrome. The page also flickered while scrolling.
It rendered fine in all the other browsers.
The solution, in my case, was to remove {mix-blend-mode: multiply;} from an element on the page. This resulted in all of the weird render bugs going away.
I hope this is of use to someone else as it took over a day of head-scratching to figure this out.
Had a very similar issue on two separate projects, and this only happens in Chrome on desktop (both Mac and Windows) and Chrome for Android.
Here's what i found:
It appears CSS animations have a limited visible 'render area'.
When you apply an animation to a element using 'forwards' it remains in this state and 'render'.
This also leads to animation lag when you are animating in multiple elements within the container element that is stuck 'forwards'.
Solutions i found to work:
Reduce the animation 'area' i.e: animate elements with a smaller pixel area, not large containers.
When wanting to animate large container elements i.e: fading in all content - do not apply the animation to the container. Create an element that fully overlays your content, and animate (fade out) that instead.
#TimothyBuktu solution above helped point me in the right direction.
For some reason, black boxes are displaying in random spaces in Chrome (latest build).
Some of these boxes are appearing outside of the main container, whereas some are appearing inline, covering content blocks. They appear randomly, usually after scrolling, and will often disappear when opening the inspector, hovering over elements, or scrolling down and back up.
For reference, there are some animations, box-shadows (which have been disabled with no luck), linear gradients, and position: fixed elements on the page, although this is not an issue with browsers other than Chrome.
This has been widely reported in user testing, although I have not been able to conjure up a fix. I am not sure if it is a CPU or graphics card issue, as the site is relatively lightweight and I am browsing with a new laptop with 16gb ram. My old Mac Mini, with 4gb of ram, does not produce this issue.
Any pointers would be most appreciated.
Update: This was a bug in Chrome and was fixed: https://code.google.com/p/chromium/issues/detail?id=142038
eddz filed the issue at crbug.com/new and over 40 people starred the ticket to follow along. It led to a few separate fixes in Chrome by the engineering team.
I had this issue with a website that was using transformZ (0) to force GPU rendering. When I removed this style the issue disappeared
This isn't an answer, but if you are able to somehow reproduce it maybe later on down the road:
Make a copy of the page locally, or anywhere, set the base href to the main domain, now start removing css links and js scripts from the bottom to the top until you don't experience the behaviour anymore, if you get to that point then the last script/stylesheet you removed is the culprit.
If you find the culprit file, now try finding the culprit line/section.
If you don't get to that point, it may be the browser, but it doesn't sound like it is.
It may also be linked between scripts/stylesheets and/or accidentally inherited.
We had experienced this weird blocks too on our website. In past we was using transitions, transitions was reproducing another bug "weird lines" randomly appeared on page and dissapear during scroll.
Now we start using transformX-Y, may be in some places Z too. And we have got this hell bloack blocks.
It seems something wrong in Chrome with transfom + transition animations. May be this bug appear when too much blocks animated at one time?
FF works fine.
I encountered these same boxes. For me, the problem was that I was using mp4 videos, which are deprecated in chrome, instead of webm videos.
I think is related to the GPU I had the same issue on my website. And it stopped happening when I turned on the Metal Rendering flag.
My website renders back bgs randomly while scrolling. It is really heavy on videos and animations and looks like chrome has so little GPU available that graphic intensive website doesn't work correctly on blink. I noticed that when chrome used webkit those issues didn't happen.
I this is a blink render issue.