Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Optimizing animation performance in WebKit on Linux

How does one optimize a compiled WebKit browser to take the best advantage of the GPU?

Background

My team and I are working on configuring a Linux box (CentOS) to display full screen HTML with smooth, CSS-driven animations. The box has more than adequate GPU and CPU power and is able to play back these animations easily in Chromium.

However, we are attempting to use pure WebKit to render these animations both by using WebKitGTK+ in Python and by compiling WebKit to a simplistic browser from the source.

Current Status

In both "pure" webkit applications, the animations are vastly slower than on Chromium, which is making us scratch our heads to answer what exactly is different between the two. We understand Chromium uses Blink, a fork of WebKit, and we currently believe the difference in performance is due to the fact that Chromium, Safari, and other WebKit-based browsers each use their own graphics component that is separate from WebKit and Web Core itself, based on what we've read.

It would be great if we could customize our WebKit build to perform even to half the specs of what we're seeing in Chromium but we're not sure where to start.

I'm wondering...

  1. Is our assumption about the separate graphics component correct?
  2. What options exist for us to optimize CSS animation performance in a "pure" WebKit browser such as ours?
like image 456
Adam Grant Avatar asked Jan 30 '18 00:01

Adam Grant


People also ask

Does WebKit need animation?

WebKit-based browsers (including Opera 15 and later) still require the -webkit- prefix for animations today, and transforms are only unprefixed in recent versions of Chrome.

What is WebKit in CSS animation?

WebKit now supports explicit animations in CSS. As a counterpart to transitions, animations provide a way to declare repeating animated effects, with keyframes, completely in CSS. With a recent nightly build, you can see the above animation in action.

Does CSS animations affect performance?

TL;DR # Take care that your animations don't cause performance issues; ensure that you know the impact of animating a given CSS property. Animating properties that change the geometry of the page (layout) or cause painting are particularly expensive. Where you can, stick to changing transforms and opacity.

Which browser would support the WebKit animation parameters?

Browser Compatability This property is a proprietary extension that is only supported in Chrome and Safari browsers.


1 Answers

I am not sure if i can help you with your Project, but one of the things i have learned lately is that we can hardware-accelerate graphics-intensive CSS features by offloading them to the GPU for better rendering performance in the browser.

Right now most of the modern browsers are shipped with hardware acceleration. They will use it when they see that the DOM will benefit from it. A strong indicator is the 3D transformation.

Lets say that you wanna place your DOM with a position absolute and raise it above the parent container. Instead of that you could actually use -webkit-transform: translate3d(10px,10px,10px); That will resolve into a 3D rendering even if we don't animate the element at all. Even if you set zero values, it will still trigger the Graphic Acceleration.

TIP If you see any flickering then try adding -webkit-backface-visibility: hidden; and -webkit-perspective: 1000;

Now lets talk about the basics of CSS

You should know that the most important thing about how browsers READ your CSS selectors, is that they read them from right to left. That means that in the selector ul > li img[alt="test.png"] the first thing interpreted is img[alt="test.png"]. The first part is also referred as the "key selector".

So first things first, IDs are the most efficient, leaving universals the least. So you could rewrite your CSS code replacing the global ones (when aren't really needed) with IDs.

An other way of slowing your browser down is by adding the global selector upfront. (div#my-div) Something that Chrome is actually doing by default on inspect mode. That will GREATLY slow your browser down.

By far the worst case is the Descendant selectors. Even a selector that fails (when your selector doesn't match anything) is better than html body div ul li a { }

One more thing, that is extremely helpful and clean is the CSS3 selectors (:last-child). Even if those selectors help us and make our life easier, they rip your Browser down. You might not see any difference in performance on a small scale application, but when you introduce them in Enterprise Applications, you will notice that they are slowing down your Rendering.

So to sum up. I just told you that replacing all of your selectors with IDs and applying style on every single element by ID will make your app super fast, but on the other hand it will be a bit silly. It would be extremely hard to maintain and also non-semantic. Thus you should consider replacing most of the selectors with IDs but don't sacrifice semantics / maintainability for efficient CSS

Also you could check an interesting test here.

Now that i think of it, i should start with the CSS basics. Oh well, i hope i helped you even a little with your Project. Cheers

like image 98
Giannis Faropoulos Avatar answered Oct 02 '22 12:10

Giannis Faropoulos