Switching to a tab with the attached testcase loaded lags noticeably (300+ ms) while painting on a relatively new macbook. The testcase has many elements with these rules (the more you add, the longer the lag): background-image:url(button-code.png); opacity:.3; display: inline-block; width: 16px; height: 16px; Replacing background-image with <img src=> makes the page paint instantaneously. Chrome handles both fine. (Found this while trying to reduce a CKEditor-using page on the new developer.mozilla.org, which lags noticeably when scrolling because of slow painting and position:fixed, I think.) This might be related to bug 523298, but it's hard to tell.

<img> is fast because we create an ImageLayer for each image in its inactive BasicLayerManager (since it's the only thing in its ThebesLayer), which ends up calling gfxContext::FillWithOpacity, which clips to a rect and then does either cairo_paint_with_alpha or DrawTarget::FillRect. background-image, on the other hand, does a PushGroup, draws the image to the group, then does a PopGroup and draws the result back. So everything's going through a temporary surface. We could making background-image do something similar to <img>. However, it would only work if background-image is the only thing drawn inside each opacity:0.3. Nickolay, is that true for the page you care about?

Thanks for the quick reply, Robert! The page(s) I care about is any page using ckeditor with the default theme, e.g. http://ckeditor.com/demo . Each button on the toolbar is implemented as: <a style="opacity: ..."> <span style="background-image: ...">&nbsp;</span> </a> I'm not familiar with our painting code, so I'm not sure if this is a 'yes' or a 'no' to your question...

Yes, I can make that work.

This is actually slightly tricky since ckeditor uses spriting with background-position :-(.

FWIW, I can no longer reproduce neither with nor without e10s. This is on newer hardware though.