Is there a reason clip path a div with an image inside slows performance in chrome?

Question

I have a div that uses:

  -webkit-clip-path: polygon(0 0, 100% 7%, 100% 100%, 0 100%);
  clip-path: polygon(0 0, 100% 7%, 100% 100%, 0 100%);

And there is an image inside this div inside another div. Is there a reason why this specific code causes chrome performance to drop - scrolling becomes choppy too. In Firefox everything looks normal.

Strangely enough, it only affects scrolling when view is on that element, once you scroll past it looks fine again

Answer 1

Clip-Path GPU Rendering

clip-path uses the GPU for rendering, so it is likely to be a graphics card/driver issue or that your system was out of resources and unable to render it effectively.

Try viewing on other machines to see if the same problem exists.

To understand the performance issues and how to debug them these articles will help

Debugging a Canvas Element

Chrome allows you to profile and debug canvas elements from the Developer Tools. It can be used for both 2D and WebGL canvas projects.

To be able to do this, you need to have enabled the "Experiments" tab. If you haven't already, navigate to chrome://flags and enable the option marked "Enable Developer Tools experiments". You'll need to press "Relaunch Now" button at the bottom of the page to apply your changes. Go to the Settings panel of Chrome Developer Tools by clicking the cog on the bottom right. Click the "Experiments" tab and check the option "Canvas inspection".

Now visit the "Profile" tab and you will see an option called "Capture Canvas Frame". The Developer Tools may ask you to Reload the page to use the canvas. Pressing "Start" captures a single frame of the canvas application. Alternatively, you can click the box below to switch to "Consecutive Frames" which allows for capture of multiple frames.

Chrome creates a log of each call to canvas, providing a list of each call to the context and a screenshot. You can click one of the log items to replay the frame in the Developer Tools and see which commands were called in the order they were called and from which line.

Firefox has Canvas and WebGL Shader debugger, giving you features to inspect frames, fps, modify shaders and more.

In order to enable these tools, go to Devtools settings (the cog icon in devtools) and check "Canvas" and "Shader Editor".

Picking Your Properties

Animation is not selecting a syntax, it’s designing the animation for fast rendering. The difference between a smooth, life-like animation and a janky, stuttery one is rarely as simple as CSS versus JavaScript. Instead, it’s often determined by which properties or attributes you animate, on which elements.

Regardless of whether you’re changing a style property with CSS or with SMIL or with JavaScript, the browser needs to determine which pixels on the screen need to be updated, and how.

If the DOM and style computation steps determine that no styles or SVG rendering attributes have changed for any elements, the browser can stop right there.

If the changed styles don’t affect layout (only painting), or if layout has changed for some elements but not for others, the browser has to determine which parts it needs to repaint. This region is known as the “dirty” rectangle of the screen. Elements elsewhere on the screen can be skipped, their pixels unchanged for this update.

The changed element usually needs to be repainted, but also maybe others. Did the changed element overlap another element, which is now revealed? If so, the browser may need to redraw that background element.

But maybe not.

It depends on whether the browser has the original pixel data for the background saved in memory. The graphical processing units (GPU) in most modern computers and smartphones can keep a certain number of rendering layers in memory, not just the final version that appears on screen. The main browser program may also save partial images in memory.

Much of browser rendering optimization comes down to how it selects which parts of the rendered document to divide into separately cached (saved) layers.

GPUs can perform certain operations on the cached rendering layers, and are highly optimized for the limited number of operations they can do.

If browsers know that an element is going to change in a way that can be efficiently calculated by the GPU, they can save that image’s pixel data in a different GPU layer from its background (or foreground). The animated changes can therefore be applied by sending new instructions to the GPU for how to combine the saved pixels, instead of by calculating new pixel values in the main processor.

Tip Most browser Dev Tools now have options to highlight the “dirty” paint rectangles whenever they are updated. If your animation is being GPU-optimized, you won’t see any colored rectangles flashing when you run this Dev Tools mode.

Of course, all GPU-optimized pathways are conditional on having a compatible GPU available—and on the browser knowing how to use it, which may depend on the operating system. So browser performance, and sometimes even browser bugs, will depend not just on the browser version but also on the OS and hardware.

Most GPUs can adjust opacity of the saved layers, and translate them to different relative positions before combining them. They can also perform image scaling, usually including 3D perspective scaling—but the scaling is calculated on a pixel level, not a vector level, and can cause a visible loss in resolution. More advanced GPUs can calculate some filter operations and blend modes, and masking of one image layer with an alpha mask layer.

Some GPUs also have optimized vector rasterization, which can calculate high-resolution vector shapes for use as clipping paths of other vector levels. These “clipping paths” aren’t only used for clip-path effects, though. Filling and stroking a shape is clipping the paint image layer to the fill-region or stroke-region vector outline. Similarly, CSS border-radius effects are vector clipping paths on the content and background image layers.

But you currently can’t rely on your end users having these optimized pathways.

The best performance, across a wide range of browsers and hardwares, comes from animations that can be broken into layers (of elements, groups, or individual graphics) that are animated in the following ways:

opacity changes

translational and rotational transformations

Warning Currently, Chrome never divides an SVG graphic into different GPU layers (although they do other optimizations).

To create a fully GPU-optimized animation in Chrome, you can sometimes position separate inline elements over top of each other, creating your own layers.

If you can’t define your animation entirely in translation and opacity layers, consider the following guidelines:

Minimize the size of the “dirty” rectangle at each frame.

Solid-color objects are better than semi-transparent ones, since the browser doesn’t need to calculate pixel updates for shapes that can’t be seen behind a solid object. (Although this may not apply if the browser is using GPU layers for optimization.)

Moving elements around is more efficient than changing what they look like. (Although it depends on the browser whether “moving around” only applies to transform movements or also to other absolute position changes.)

Changing fill and stroke is more efficient than changing shapes and sizes.

Scaling transformations are better than changing the underlying geometry; browsers may be able to use GPU image scaling for an animated scale effect, instead of recalculating the vector image at the correct resolution at each frame.

Clipping is usually more efficient than masking.

Avoid rescaling gradient and pattern layers; this could mean using user-space effects instead of bounding-box effects, if the bounding box is changing.

Avoid any changes that require a filter to be recalculated. That includes any change to the filtered element or its child content.