Why is S5 slow in Mozilla? (23:08 -0700)

Tantek pointed out to me that S5 presentations get really slow in Mozilla when they have a lot of slides in them. I did a quick profile, and it's clear that the problem is painting.

I'm not sure if there's anything simple that Mozilla could do to fix the problem. In Mozilla, S5 styles the content by making the slides all on top of each other, fixed positioned, with transparent background, and underneath (z-index-wise) the footer but on top of the header and the body's background. It then uses the CSS 'visibility' property to hide the slides that aren't being shown.

The 'visibility' property isn't particularly easy for browser to optimize based on, since it's an inherited property, and an element with 'visibility:hidden' is allowed to have 'visibility:visible' descendants. Fixing Mozilla to track whether elements with 'visibility:hidden' have any visible descendants might fix this problem, but it could easily introduce performance problems in other cases, and it's also a bit of work.

One fix for the performance problem is for S5 to use 'display:none'. That allows the type of easy optimization (for browsers) that 'visibility:hidden' does not, since elements within an element with 'display:none' cannot be shown. This has a disadvantage for something like a slideshow: it means that resources on slides that are hidden might not be loaded until the slides are shown, which isn't something you want if you're giving a presentation on a less-than-reliable network.

I'd have thought that S5 doing the hiding using 'clip:rect(0,0,0,0)' would fix the performance problem, but it didn't. Mozilla should be able to make that S5 change fix the performance problem. It might be an interesting (and hopefully not too difficult) Mozilla programming exercise to do that. The fix probably belongs in one of the files in the view code. (View objects in Mozilla exist for some layout objects (which Mozilla calls frames) — generally those layout objects that have more interesting compositing or z-ordering properties.) At least, that's probably where the fix belongs as long as the view code is still around, which it may not be for much longer, since redesigning it may be needed to fix an important z-ordering bug that affects the Acid2 test.

I filed a bug on doing this. Please do not comment on the bug unless your comments contribute to getting the bug fixed.

There may be other workarounds for S5 that involve using 'z-index' differently (which probably also requires giving something other than the body a non-transparent background). Those would require rather more involved changes to S5, though, and I'm not even sure they'd work.

(It also doesn't help that Mozilla seems to repaint more than once for each slide change. That may be a harder bug for a newcomer to fix, although it may not.)