We Keep Coding

Google Chrome hardware acceleration/css scale causes faulty compositing

The background:
I am making a 2D HTML/CSS animation using JQuery. This will place roughly 25 same-sized images on top of each other, moving some as desired. UI elements get a pixel position and are much smaller than the full-sized images. I have recently moved from forcing hardware acceleration form backface-visibility: hidden to will-change css properties. The entire animation is scaled by the div it is contained in and the css transform property.
The problem:
In Google Chrome specifically, the compositing starts malfunctioning in certain scenes, in a reproduceable but seemingly random manner. Images are partly cut off, images are placed behind images they are supposed to be on top of, the like. Scrolling up and down replaces some malfunctions with others, as does changing the display properties of some items (happens due to UI interaction).
The question:
What is causing this behaviour, why are all my other test browsers (firefox, opera, internet explorer, edge) not affected, and how can I avoid it?
My current status:
From what I have tried so far and my gut feeling this is an issue caused by overuse of hardware acceleration or the transform: scale css property, or a combination of both. I'm currently working on other scaling methods as the easiest "fix" to the problem, but I still do not know what is causing all of this. Sadly all of my UI elements aren't a neat % of the parent.
What I tried:
Firstly I tried setting the z-index for all elements manually. This accomplished nothing, sadly.
As sometimes scrolling up/down or interacting with the UI seemed to fix problems, I tried adding a method that would force the browser to re-do the layout at certain points in code. This argueably only made things worse, as it added a lot of white flickering, and failed to fix the issue.
I tried switching animation libraries from jquery to velocity, which did not help.
I removed the "hack" that forced things into hardware acceleration. This fixed the compositing problem, but reintroduced choppy animations in chrome (only).
I then tried to assign hardware acceleration on a need-to-get basis by adding and removing a css class containing the "hack". The behaviour was the same as in 4 .
I tried using will-change instead of the backface visibility hack, but this just set the behaviour back to where it was before I started my attempts at fixing this.
I tried reducing the amount of layers while keeping hardware acceleration. I used jquerys ".hide()" on elements only animating once replaced the final picture with a singular image. This did not fix the issue of composite "mashup".
Finally, I disabled the css transform scale property, which fixed the unexpected behaviour, but is imperative so I can scale my animation for screen size.
Some code:
Here's some css code of the animation container
.animationContainer {
position: relative;
width:2560px;
height:1440px;
/*transform: scale(0.55);*/
transform-origin: top left;
overflow: hidden;
display: inline-block;
}
And some javascript detailing the animation I use for the majority of objects, making them "fall" into the scene
function fadein(el, direct)
{
var falldistance = 150;
$(el).show();
$(el).css("opacity", 0.0);
switch(direct) {
case 0:
$(el).css("top", "-="+falldistance);
$(el).animate(
{
top: "+="+falldistance,
opacity: 1.0
}, 1000);
break;
[...]
I do not know how useful more code would be, if you require any more please ask. Web design isn't a field I have much experience in, and I am slowly running out of ideas. Any help or suggestions would be appreciated.
Example Visual:
This is an example of one of the bugs:
This is what it looks like after scrolling down and back up in the browser:

Something caused this CSS to break

I have a static site based off a theme. The CSS has not been touched but something caused it to break recently. I was a bit confused since I hadn't made any changes so I checked the example site and it's broken there as well. I checked with the author, no new changes but they also noticed it's broken for them now.
So the issue. On Safari, IE, Chrome, and Edge there is a weird header weird "pop-in(?)" upon page load. All elements are shifted down immediately. Firefox operates properly.
It's easiest to see on this page https://mmistakes.github.io/so-simple-theme/theme-setup/, but effects all pages in the theme.
I'm not a CSS wizard but after troubleshooting for a day I found it may be related to this CSS selector? I could be completely wrong.
#site-nav {
display: none;
z-index: 5
}
Second question (less important) is I'm wondering what could cause something to break after the fact. I'm assuming one of the JavaScript libraries linked in?
Thanks much!

You are correct, the reason your content, say "pops-in" or simply shifts down abruptly is because the content just appears when page is loaded.
To fix this initialize your CSS to start like:
#site-nav {
height: 0;
transition: height .2s, max-height 200ms;
overflow: hidden;
}
Then in your #media for 48em have your css do this:
#site-nav.closed {
height: 5em;
}
This will ensure your content actually slides in and no abrupt behavior exists anywhere.

Duplicate HTML or move elements with JS for responsive site

There's site I'm working at and design for tablet/mobile devices require me to move elements (from left sidebar to right, change order, etc.). These elements include simple text and images (pretty small, logos).
My question is, what would be the best way to go about this? So far I have only two ways.
1) Duplicate HTML content and then show/hide with CSS media queries. My concern here is that it's not SEO friendly, and content / images still gets rendered, even if hidden. Could that leave me with a performance problem?
2) Move elements using JS. My concern here is that people with JS disabled will still see the content in old places, and maybe this JS solution could impact performance even more?
Would really appreciate some input on best practices in a situation like this.
Here's what I'm trying to achieve:

The questions are contradicting a bit :)
First of all, it's 2016 in the WEB, if you are speaking about having responsive layout, support of mobiles, tablets, desktops - they will have JavaScript support, so you shouldn't worry. - it is answer on your question number #2. The percentage of people not having JS is extremely low, it's below <1%.
CSS media queries are enough to make good responsiveness. Sometimes you need to add helper methods with JS to manipulate DOM and to make it even more advanced.
You may check how they do responsiveness with classes in Twitter Bootstrap.
Sometimes content will be duplicated in HTML, but as soon as it's not visible simultaneously on the screen because of visibility rules from CSS media queries - it will not do any harm on SEO.
There's the way to over-complicate things a bit, RESS: Responsive Web Design + Server-Side Components, and to serve different HTML layouts depending on the detected User Agent.

You mentioned that you were reluctant to use display: hidden because something about them being rendered. If I'm understanding correctly, then you can use display: none on the right side for example. Then in your media queries, you can set content on the left to display: none and content on the right to display: initial. That should work just fine, if I understood you correctly. Then no space will be allocated for the hidden elements.
For example:
.leftDiv {
display: initial;
}
.rightDiv {
display: none;
}
#media screen only and (max-width: 1000px) {
.leftDiv {
display: none;
}
.rightDiv {
display: initial;
}

Chrome rendering bug, Slick.js, Flash animation

The following display issues occurs in Chrome (Version 39.0.2171.95 dev-m)
It has been observed on several Windows PCs and on a Mac.
There seems to be two culprits which can cause this, a slideshow component using Slick.js and a flash animation. I have updated Slick.js to no avail.
The content display will cut off at the same place regardless of where the component is positioned. The position appears to be fixed from the top of the page, not relative to the size of the browser.
The hidden content below will appear in blocks as you move your mouse over the area. Resizing the browsers or highlighting the text on the page will also clear it.
Whilst the bug is still live you can view it here
http://sci.esa.int
Any thoughts?
If I break slick.js by removing the js - then the Twitter component does not cause the bug.
If I remove the flash or the twitter component from the page, the bug does not occur.

I found a resolution
html{
-webkit-transform: translate3d(0, 0, 0);
}
As per another comment though I have added this code
html *:not(svg) {
-webkit-transform: translate3d(0, 0, 0);
-moz-transform: translate3d(0, 0, 0);
-ms-transform: translate3d(0, 0, 0); /*only in IE10*/
}
Chrome redraw issue
Although another comment suggests it can have drawbacks

iPad css3 animation flickers after keyboard use

I'm developing an app for the iPad using HTML5/CSS3. I'm not using any framework and am just using whatever is natively supported on the device. I have created some css3 animations to emulate the typical iOS sliding left or sliding right when navigating between screens. Here's an example of the slide left animation which is taking advantage of the iPad's CSS3 hardware acceleration: (the ipad is running 4.2).
/*************************************************
Slide Left
*************************************************/
.screen.slideleft{
-webkit-animation-duration: 0.5s;
-webkit-animation-timing-function: ease-in-out;
}
.screen.slideleft.outgoing{
z-index: 50 !important;
-webkit-animation-name: slideleft-outgoing;
}
.screen.slideleft.incoming{
z-index: 100 !important;
-webkit-animation-name: slideleft-incoming;
}
#-webkit-keyframes slideleft-outgoing{
from { -webkit-transform: translate3d(0%,0,0); }
to { -webkit-transform: translate3d(-100%,0,0); }
}
#-webkit-keyframes slideleft-incoming{
from { -webkit-transform: translate3d(100%,0,0); }
to { -webkit-transform: translate3d(0%,0,0); }
}
I also have this CSS which I've attempted to use to fix the flicker:
.incoming,
.outgoing{
display: block !important;
-webkit-backface-visibility: hidden;
}
This works great until the iPad keyboard is used. After which point all the animations flicker severely.
I've been looking for examples of an iPad HTML5 app that uses the keyboard and doesn't have flickers afterwards, but haven't turned up much. The jqTouch demos exhibit the same behavior on the iPad (although I know they were designed for the iPhone).
I've turned up a few posts/questions of similar questions but have never found a good answer. I've been through http://css3animator.com/2010/12/fight-the-flicker-making-your-css3-animation-bomb-proof/ and the articles linked there but haven't had any success.
Any other suggestions?
Update 1/13 # 9am
I've added this css and it helped a lot:
.incoming *,
.outgoing *{
-webkit-backface-visibility: hidden;
-webkit-transform: translate3d(0,0,0); /* This helps with the flicker a lot. */
}
The foreground elements don't seem to flicker anymore, but the backgrounds still do. Still looking for some help or helpful resources on Mobile Safari's memory handling tactics.
Update 1/16 # 11pm
Increasing the z-index as suggested by anonymous. Didn't seem to make a difference.
Update 1/17 # 8:30am
I've posted a demo of the problem here.
The transitions between screens work great...until you tap/click inside one of the form fields. After the keyboard slides up and returns, all the transitions flicker. Go to the URL inside the iOS simulator or on an actual iPad to see what I'm talking about.

This is an old question, but I thought I'd share my experience.
I've been having issues with outrageous flickering (on css3 animations) on the iPad (as well as the iPhone, but in that case only in portrait view). I was able to completely resolve all of the flickering issues by setting :
-webkit-perspective: 0;
On the elements being animated. I'm not sure why this works, but it does (tested on iOS 4.2+, both iPad (1 and 2) and iPhone 4).
Update: I've just become aware of an issue with Chrome when setting the value of that attribute to 1. It works just fine when it's 0, so I've updated the above appropriately.

Looking at your source, the translate3d(0,0,0) isn't applied until the transition starts?
Try
.screen{
-webkit-transform: translate3d(0,0,0);
}
or
.screen *, .screen{
-webkit-transform: translate3d(0,0,0);
}
The flicker is probably the hardware acceleration kicking in (it currently only works on 3d translated elements).

I had the same issue, but i was able to reduce the flicker to almost unnoticeable by applying the fix described here and here:
http://code.google.com/p/jqtouch/issues/detail?id=301
https://github.com/senchalabs/jQTouch/issues/issue/130
Basically set the z-index of the page you a are moving out to -1 and after the transistion back to 1

I know this is a dinosaur old question, but there is a solution for this issue and it is quite lightweight and very simple.
document.getElementById('clicked_input').addEventListener('focus', function(e){
e.stopPropagation();
},false);
When i was tackling this issue too, I thought I tried everything - eventually the only thing that helped, was to create a modal window (position: absolute) outside of the app's container div, and also set the app's container div to display:false; when the keyboard was coming up. While it worked it was ugly, I tested everything to see what caused the event and it seemed that when the 'focus event' bubbled up, every 3d transform gets messed up (in flickering and performance).
Preventing the event of bubbling solved this issue completely - quite mind boggling that such a hated bug had such a simple solution?

You're not going to like me saying this, but JavaScript may be the answer you're looking for. I fear that when you bring the keyboard up, the process of rendering the HTML loses priority. With a continually updating script, like a setInterval loop, the iPad will have no choice but to render as planned. Explicit code requires no hacks.

I agree with Ben, you should probably set transforms on the classes themselves as well:
/*************************************************
Slide Left
*************************************************/
.screen.slideleft{
-webkit-animation-duration: 0.5s;
-webkit-animation-timing-function: ease-in-out;
-webkit-transform: translate3d(0,0,0);
}
.screen.slideleft.outgoing{
z-index: 50 !important;
-webkit-animation-name: slideleft-outgoing;
-webkit-transform: translate3d(-100%,0,0);
}
.screen.slideleft.incoming{
z-index: 100 !important;
-webkit-animation-name: slideleft-incoming;
-webkit-transform: translate3d(0,0,0);
}
#-webkit-keyframes slideleft-outgoing{
from { -webkit-transform: translate3d(0,0,0); }
to { -webkit-transform: translate3d(-100%,0,0); }
}
#-webkit-keyframes slideleft-incoming{
from { -webkit-transform: translate3d(100%,0,0); }
to { -webkit-transform: translate3d(0,0,0); }
}
If that doesn't work, I'd be curious to test if only translating the X with translateX(-100%) fixes the problem. (Not necessarily a fix, because you don't have hardware acceleration without 3D transforms, but would help narrow down the problem.)

Ultimately, there really wasn't a fix for this issue. It seems like form elements in WebKit on the iPad cause problems with flickering.
My workaround was that on the onblur of each form element, I refreshed the page using hash tags to ensure it refreshed to the exact same state. It still caused a "flicker" while it was refreshing, but it did keep the screen from flickering throughout the rest of the app.

I've recently been having the same problem and tried all sorts of complicated fixes. In the end I found the issue was down to the default styling on the input. I fixed my problem by adding the css input{outline:none}. It's prob just on the focus state so input:focus{outline:none;} should work.