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.)