using:
Chrome 36.0.1985.125
Foundation Orbit 5.2.2 with animation: slide
I have a slide show, 5 slides, at the top of my page. They are set to transition via slide every 3000 ms.
I first noticed the repaint issue described below due to Fancybox being called near the bottom of the page. While the Fancybox iframe was "popped out" there would be a quick white flash / flicker affecting everything apart from the iframe, every 3 seconds.
Using Chrome's inspector's Timeline view as well as the Rendering option to "Show paint rectangles" proved my suspicions correct.
Even when the slide set (the top of the page) is off screen, still every 3 seconds there is a page-wide repaint. With the inspector's Timeline, I can see a "heartbeat" every 3 seconds in the flow, even when scrolled all the way to the bottom of the page, including a large purple and green spike, where purple represents rendering and green represents painting. With the Rendering option "Show paint rectangles" I see, again even when scrolled all the way to the bottom of the page, a quick flash of every element on the page framed and tinted in green (being painted) every 3 seconds.
I've looked around quite a bit for "foundation orbit flickering," "orbit slideshow repaint" "foundation orbit repaint offscreen," and similar terms and have so far not discovered anything of use.
One or two pages I read mentioned a font change or font flicker at regular intervals relating to the slides' transitions. The "fix" (or workaround) there was to change the animation parameter's value from slide to fade. Trying this, I found that the repaint issue went away completely. However, I would prefer to use the slide transition.
I haven't been able to reproduce this in Safari or Firefox, but I also don't know what developer tools to use in either of those browsers that would confirm or deny whether the repaint is occurring (i.e. the equivalent of Timeline or "Show paint rectangles" in Chrome's inspector). Failing that behind-the-scenes proof, it is the case that in Firefox and Safari, with the Fancybox iframe popped out near the bottom of the page, there is no white flash / flicker, as there is in Chrome due to the repaint.
Any help would be greatly appreciated.
And yes, I realise that the Foundation Orbit slideshow is no longer supported.
Many thanks.
Related
I've got an issue going on with my CCleaner internet web browser (which is built on Chrome). These silver-white borders appear over elements on web pages, and even the whole page itself, whenever I click on such an element. It only happens inside the CCleaner browser window, not in "regular" Chrome.
Here I would like to provide an example, taken from my edit account settings here on Stack Overflow dot com (a page you can look at that is exactly the same as mine except for my issue with my web browser).
OK so in that pic the border you see around the text entry box is what I get all the time. The box is not permanent; it slowly fades out and dissolves.
How do I prevent these silver borders from appearing in the first place?
I have a site (http://www.iproconnect.com.au/) that for one user (that I know of) renders the home page with black areas in Firefox. These do not seem to be tied to CSS, as if I force a re-draw of an affected area (e.g. by scrolling areas in and out of the viewport) it sometimes renders correctly, and sometimes incorrectly but differently to the previous incorrectly. Also if I do this with the inspector open, no CSS seems to change, and hovering background URLs show the image downloaded correctly.
I can't reproduce this in other installations of Firefox (all running the same version - fully up to date). And this user has un-installed and re-installed with no change in behavior.
I don't even know how to debug this further, let alone how to solve. Any ideas greatly appreciated.
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 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.