See <http://hg.mozilla.org/mozilla-central/file/247b6aed5414/browser/themes/winstripe/browser/browser.css#l302>, <http://hg.mozilla.org/mozilla-central/file/247b6aed5414/browser/themes/winstripe/browser/keyhole-forward-mask.svg> and <http://hg.mozilla.org/mozilla-central/file/247b6aed5414/browser/base/content/browser.xul#l639> Twinopen numbers from the tryserver: > keyhole-forward-mask.svg#mask browser.xul#winstripe-keyhole-forward-mask > XP 146.68, 141.95 118.26, 119.32 > Vista 126.56, 127.63 122.58, 121.47
Hmm. The non-external thing just needs a single getElementById call. The external one needs to go load a separate file from disk. Not only that, but it starts the load fairly late, I would think: the first time the masked element needs to be painted, right?
Correct, the paint triggers it so you get at least 2 paints in the external SVG case.
Is this expected/desired/required behavior or something that can and should be changed?
It's expected at the moment. It's not required. Whether it's desired depends on how people use SVG resources and stylesheets in practice... If it's common to have stylesheets that reference external resources but have rules that don't match anything in the document, then preloading all the external resources at stylesheet parse time would be bad...
(In reply to comment #4) > If it's common > to have stylesheets that reference external resources but have rules that don't > match anything in the document, then preloading all the external resources at > stylesheet parse time would be bad... Would it be somehow feasible to make this opt-in? Or make it an exception for chrome documents?
Preloading for XUL documents seems reasonable to me. XUL already avoids incremental rendering.
I assume comment 5 means XUL stylesheets, right? Note that since those are shared across documents we can't really do parse-time loading; we simply don't have the right context at that point. We could load at style resolution time, perhaps, instead of paint time....