#VelocityConf: The CSS and GPU Cheat Sheet

Today, I also attended a talk on CSS and GPU interactions and exactly how they work, at least in Chrome. The insights are very helpful, though. My biggest concern with this information is how little it may translate to other browsers. If Chrome chooses a certain way to split rendering tasks, what is to say that IE or Firefox will choose the same mechanism.

In any case, the idea of the web page having layers is very important. All of the translate, scale, and rotate properties that deal in 3 dimensions will move the element into its own layer. In Chrome, this gives it a different frame buffer to work with. Doing this can give you some big benefits, especially when elements move in relation to each other. The best analogy is to consider the layers as reference frames from physics. Each component that moves in relation to another is in a different reference frame from the target. That way, the GPU can optimize how it deals with the various frame buffers and combines them.

Obviously, a lot of frame buffers will cause a performance degredation as the browser will spend a lot of time (and graphics memory) trying to manage them all. However, I wonder how this works on the browser with dozens of tabs open. At what point doesn't this matter anymore. I know we want to provide the best possible user experience, but limited memory for the GPU means that there is a limit for the entire system. It seems that your website performance may be affected by another tab using all of the graphics memory. If the user switches back to your site, you may have some significant responsiveness issues that are completely outside of your control.

blog comments powered by Disqus