Google Chrome hardware acceleration/css scale causes faulty compositing - javascript

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:

Related

Is there a fluid CSS height property for elements entering the DOM? Jank happens when using Semantic-UI-React Transitions

I am not sure if this is the proper place to ask this question; I considered Software Recommendations however I figured I'd give it a shot here first.
I am creating a PWA and with every iteration I'd really like to focus on making it look/feel like less janky and as smooth as possible. Well, like a native app.
So here is the problem—I am using transitions (animations) provided by Semantic-UI-React, and while it works beautifully when an element which is occupying its on space, I was wondering if there a practice or pattern which handles the behavior of adjacent DOM elements to one that is being animated?
I supplied a GIF below to illustrate what I mean. I suppose I could just move the animated elements out of the container of the form to prevent jank, but I wondered if there was a more elegant pattern or approach to this...
Merci!
Unfortunately, there is no particularly elegant approach to this.
Regarding the question in the title of your post, a common approach is to animate the height of the new elements. If you don't know the height of the elements, unfortunately animating from 0px to auto does not yet work but you can fudge it by animating max-height from 0px to a value slightly larger than the maximum size you expect the element to be.
But don't do that.
It will cause the browser to layout the page on every animation frame and will almost certainly jank on lower-end devices.
Instead, you're better off to animate transform.
The most common approach is to:
Grab the original position of the elements (using getBoundingClientRect() etc.) that are going to be affected just before you add the new elements to the DOM (perhaps using getSnapshotBeforeUpdate unless you're using hooks, in which case you can use useRef to similar effect).
After you've added the new elements (which you're presumably also animating in by using transform with a suitable scale() function), calculate the delta from where the offset elements are now, compared to where they used to be.
Setup a transform animation from the negative of the delta, to zero (i.e. the FLIP approach). E.g. if the element has been shifted 300px down the page, animate transform from translateY(-300px) to none.
Of course you need to do that for all the elements in the flow that are affected so it might be easiest to put them all in one container and just animate that.
Regarding the third point you have a few choices of technology, none of which are great:
CSS transitions. These are simplest but you'll have to trigger a style flush to get the negative delta starting point to stick. e.g.
elem.style.transform = `translateY(-${offset}px)`;
elem.style.transition = `transform .3s`;
getComputedStyle(elem).transform; // Flush style
elem.style.transform = `none`;
CSS animations. Producing #keyframes rules dynamically using the CSSOM is a pain but at least you don't need to trigger a style flush (and you can set an animation with an implicit to-keyframe for convenience).
#keyframes random-id { from: { translateY(-300px); } }
Web animations. This is probably the most well-suited.
elem.animate({ transform: [ `translateY(-${offset}px)`, 'none' ] }, 300);
// In future when browsers ship support for implicit to/from keyframes:
elem.animate({ transform: `translateY(-${offset}px)`, offset: 0 }, 300);
Unfortunately Safari only has Web Animations support in Tech Preview so Safari users will get the un-animated version until the next Safari release. Edge users will also get the un-animated version until the Chromium based Edge ships. There is a polyfill too but it's not actively maintained at this point in time.
If you're using React, Animating the Unanimatable is a helpful article on all this.
The other tricky part is making sure the scroll doesn't jump for which you might need to look into scroll anchoring.

React App CSS Transitions Are Very Slow

I have a simple blog that i'm developing using create-react-app (using react-scripts#next to get CSS Modules support).
Repo
Demo
The problem i'm having is the CSS hover transitions are very laggy and slow. I previously implemented this interface using Node EJS templates and everything was snappy and fast.
I'm thinking the problem maybe has to do with the PostSummary component receiving new props and re-rendering constantly, but all the props appear to be static once they're loaded.
I checked the Chrome performance tab and it said the majority of the cycles were being used by paint time (and not load time).
Very confused, anything I can test to resolve the issue?
When you have animations that you know will fire, it's good practice to use the will-change rule, to help the browser be more efficient.
Adding the following rule improves performance in Chrome substantially:
will-change: transform, box-shadow, z-index;
Also, check out this article. It provides AWESOME tricks to help improve the performance and animations on your website.
https://medium.com/outsystems-experts/how-to-achieve-60-fps-animations-with-css3-db7b98610108
One thing I see is that on hover you're changing the z-index. That has a possibility of slowing things down, so just be mindful when using any of the positioning rules. The transform: translate rules are much more performant than top, left, right, bottom, z-index. Not sure if you can get around using z-index or not with your design, but it's good to keep it in mind anyways.
Animating large images will cause performance issues. The first image in your example is: width: 5264px; height: 3393px;. Optimize the images for web and they should load quicker and animate smoothly.
Consider animating text and pure HTML elements, but try to avoid animating large images.
When you resize an image by transitioning it has to render the image multiple times during the transition and is very "expensive".

Layering issue with Adobe Edge on iPad only

I have a fairly simple button symbol that I'm adding dynamically to the stage. The button has a background layer and a text layer. Everything works fine in the standard browsers but on iPad the background layer unexpectedly covers the text (as if on a higher z-index though no value shows in the DOM and attempts to override the z-index via css do nothing). Further more this issue only seems to trigger when I go to a label in the button such as;
button.stop("Idle");
Has anyone else had random layering issue on iPad that may relate to this?
For anyone who may be searching; Apparently vector shapes do not appear smoothly and consistently in all webkit browsers (the primary culprit mentioned was Android native browser). As an artificial optimization you can apply a 3D transform (but without actually scaling or rotating) in order to improve the vector rendering. In Adobe Edge this is done by applying a 'translateZ" transform to all of the elements on the stage. However this also causes random issues with any item I'm trying to layer with "z-index".
The solution is to clear out this transform on the problematic elements (or edit the edge classes to removed them globally) like so;
buttonFrameSym.$("select_arrow").css("-webkit-transform", "none");

Is there a way I can force chrome to do subpixel rendering for a slow translation?

Im doing a very slow transition of a background image (a view of space that slides slowly to the left). My problem is while it looks beautiful on Firefox, it looks horrible on Chrome. I get a "jittery" effect due to Chrome's lack of subpixel rendering, and the image just snaps to the next pixel. I cannot speed the image up because it will destroy the effect Im trying to achieve. I have tried using TranslateZ() tricks, I have tried every CSS3 effect I could think of to make it look better, Ive tried Kinetic.js, Ive even tried Babylon.js hoping that WebGL would fix my problem.
At this point Im at a loss and I might just have to give Chrome users a static background and cater more to the Firefox users in regards to the neat little things I can do for the UI UX, and then just put a disclaimer on my site saying that the page is best viewed in FF.
I REALLY dont want to do this. Is there ANY work around at all?
You can force subpixel rendering by applying a small transformation:
#container {
transform: rotate(-0.0000000001deg);
-webkit-transform: rotate(-0.0000000001deg);
}
But instead of using JS to make the animation work, why not use CSS3 animations?
If you use transform: translate() browsers will use subpixel-rendering by default.
Also since the performance is better you shouldn't get your jittery/wave motion.
More info on performance here: http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/
I've put together a simple demo here: http://jsfiddle.net/yrwA9/6/
(For the sake of simplicity I only used the -webkit- vendor prefixes)

Repaint slowdown with CSS via Javascript in webkit browsers

I've been working on a slideshow script that uses CSS3 transitions, or jQuery's animate when they are unavailable. I've created a custom function to do the slide animations, which does so appropriately. Everything seemed to be working fine, but I've hit a major snag during testing.
For one reason or another, there is an large delay applying the jQuery CSS before and after the transition on large slideshows. For example, the slideshow in the link below is around 9900 pixels wide (container width, most of which is hidden). The container is maneuvered to display the appropriate slide, using CSS3 transition and transform properties. The delay occurs applying the CSS between lines 75 - 82 in the paste below. In particular, applying the 'transition' CSS causes the problem. Add the 'transition' CSS to the stylesheet (rather than applying it with JS), and delay disappears. This isn't really a solution however, because we only want to use CSS3 transitions on specific properties, that can vary (using 'all' in the stylesheet would transition some CSS that we don't want to animate, but change regularly).
Animation function:
http://pastebin.com/9wumQvrP
Slideshow Demo:
http://www.matthewruddy.com/demo/?p=2431
The real problem is with iOS, in which the slideshow (and even the browser sometimes) becomes completely un-usable. I can't pinpoint any errors, and have really exhausted my knowledge of debugging JS. I'm sure it is related to this section of the function after playing around a bit, and disabling CSS3 support within the plugin altogether removes the problem completely.
I'm completely stuck, and really appreciate any help anyone can give.
--- Edit ---
I've tried applying the CSS with native Javascript rather than jQuery's .css function. Same results, no better performance. Also worth noting that this isn't happening at all in Firefox, and seems to only be a problem with Webkit browsers.
Anyone with a solution, would happy to make a donation towards a few beers! I really cannot figure this out!
--- Second Edit ---
Ok, so been debugging and I can see that the slowdown is caused by the browser repaint cycle that is taking a very long time. Is there a better way to handle this that the way it is already doing? Positioning the element absolutely is a known way to reduce repaints, but that isn't really working because the slideshow is responsive. Absolutely positioning the slide images or the slides themselves causes it to collapse.
--- Third Edit ---
A day later, and I've made some progress. Adding 'transition: all 0s ease' to the elements stylesheet CSS has gotten rid of the repaint caused by adding the inline CSS transition property via the custom animation function mentioned in the original post. This causes a significant performance gain, especially when removing the inline CSS transition property when the transition itself has finished.
Good stuff! However, now there is still a slowdown when the inline CSS translate is being removed (that was used to create the hardware accelerated transition effect itself) after the transition, and the left positioning is being applied. When the two happen together, there is a slowdown.
Breaking them up into two separate tasks (the translate removed, then the left position added in a setTimeout with no time specified), again gets rid of the repaints = performance gain, and looks likes problem solved. But sometimes, the CSS transition property isn't get negated fast enough, and the translate removal gets animated. No good, and don't know where to look next to work around it.
I think the problem is you're loading HUGE images :)
They are too big for the container you have them in, so you scale them down, which is even more resource intensive.
Try resizing them.
First of all congrats for your debugging!
I have been working on the exact same stuff lately and found out that ios devices don't support a large number of images positionned in the same page. It causes crashes and the only solution I found was removing elements instead of just hiding them. The downside is that removing and appending elements causes lags so you have to do it cleverly, when your transitions are done. I thought the best way to go was keep 3 or 5 images in the DOM and replacing the rest with thumbnails of the images, resized to fit the original. When transitions are done, I'd just put the large images back into place...
Hope this helps you a bit on the ios problem at least...
After spending some time analysing your code TimeLine with Chrome Dev Tools, I believe there's some optimization you could do.
As far as I can tell, every single one of your 16 images gets fully repainted every time an animation is requested. This seems quite obvious to me, as there are 16 images in your example, and the Chrome Dev Tools reports 16 long "Paint" executions every time in hit "Next".
In my humble opinion, you should figure out a solution that considers only translating two images: the one you want to hide and the one you want to show. So, consider please, not moving the rest of the images and, instead, leaving them all side-by-side to the shown image.
One more thing, using scaled down images is probably making the paint cycles quite longer. Avoid them whenever you can.
Well, think I've managed to figure it out! Just so you know, original post links don't reflect the changes as I've done them on my localhost environment.
Absolutely positioning the slides container has fixed the problem that was occurring with repaint speeds after the transition had taken place (whilst applying CSS properties). Obviously taking them out of the DOM has done the trick, allowing painting to take place much more efficiently.
I originally didn't try this too much because I knew this would add a lot of work to the resizing functionality. I had originally intended to not resize at all in JS, and rely on percentages to do the dirty work. Absolutely positioning the container would cause the slideshow viewport to collapse, rendering the native resizing useless.
However, I was already having problems with sub-pixel rendering in other browsers anyway, so I guess it was time to bite the bullet and rely on fixed pixel values. I then used JS to handle the resizing, using the window resize event. All seems good, however the slideshow was still collapsed due to the positioning. Assigning height values wasn't working correctly, so was at a bit of a loss.
Thankfully, I came across a neat little trick of setting the 'padding-top' of the slideshow viewport to a percentage value, dynamically calculated (desired slideshow height, set in the settings panel for this script, divided by desired width). As padding-top percentages are relative to the width of the element, this did a great job of providing responsive height and correcting the viewport again (no longer looking collapsed).
Here is some info on using padding-top for responsive elements that maintain aspect ratio. Great little trick: http://f6design.com/projects/responsive-aspect-ratio/
All is good now, and things are working well in iOS and webkit browsers. Everything is extremely quick and working as it should. Four days later, and it is finally figured out. Not happy about having to resort to JS for resizing, but I guess it was always going to happen due to percentage inconsistencies between browsers. Lots of decimals = no good!
Thanks to all who tried to point me in the right direction. Definitely got me thinking, and learned a lot of debugging skills that I can use again to make sure transitions are performing well. Thanks again!
not sure if this helps or not but I noticed you use 3d translation - I would think a simple 2d translation would be enough especially since your third parameter is 0 and might accelerate the issue, also go with fewer images as Armel L. suggested, don't have an iphone to test though... alternatively, this is a solution I used before css3 but should still work move the element containing the images using javascript by modifying left (?and top - the demo only moves left and right though? without the transition effects) and this way you can fine-tune the refresh rate which I think might account for the slowdown... you can go as low as 18 fps without anyone noticing, might even be good enough with just 16fps
I had this when I was first designing a magazine carousel-style page device.
If you have a series of images within a long "tray", even if they are not within the viewport, they will still take up ram, and you can effectively have five or so before leaks and nastiness begin to happen.
What I found works is "hiding" them ... But make sure they take up the physical space necessary.
What I also found worked was that one could make the 'previous' current and 'next' image are visible and move the tray, 'unhiding' them as they reach those three positions.
In my own system, I skipped the 'tray' holding e images and only had them at -100% width, 100% width and the current one a 0.
I never had much luck with the typical long-tray carousel with large scale background images... Especially with css3 acceleration.

Categories