I know how it works. I wrote much of the layout and graphics code for Servo and did the initial bringup of the compositor on Firefox Mobile. You shouldn&#x27;t have to rasterize new content on every frame when you animate font-size (except for individual glyphs, but that&#x27;s still quick, just a few ms, if you parallelize it—and even with techniques like SDFs and&#x2F;or GPU vector graphics tricks like [1] you may not even need to do anything on the CPU). If you animate, say, margin-left, you should in most cases be doing essentially no work on the CPU, and you should be able to submit one draw call to repaint the page since all of the resources (images, glyphs, alpha masks, SVGs) should be cached in an atlas. It should be 1-2ms. Even animating something like border-top-width should be no resource changes and one draw call, exactly as fast as your compositor should do it.<p>Optimally implemented, I believe there should be no difference between &quot;rasterization&quot; and &quot;compositing&quot;. You&#x27;re painting the same number of pixels, paying the same fragment shading and rop cost, either way. Caching fully rendered Web content in textures assuming that the cost of rasterizing that content is high isn&#x27;t working very well, and I think it&#x27;s not worth it.<p>[1]: <a href="http:&#x2F;&#x2F;wdobbie.com&#x2F;post&#x2F;gpu-text-rendering-with-vector-textures&#x2F;" rel="nofollow">http:&#x2F;&#x2F;wdobbie.com&#x2F;post&#x2F;gpu-text-rendering-with-vector-textu...</a>