546262 - Consider pre-loading external SVG resources referenced from XUL style sheets

Status: RESOLVED WONTFIX

(Core :: SVG, defect)

Description

[Dão Gottwald [:dao]]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[Robert Longson [:longsonr]]

Correct, the paint triggers it so you get at least 2 paints in the external SVG case.

Comment 3

[Dão Gottwald [:dao]]

Is this expected/desired/required behavior or something that can and should be changed?

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Dão Gottwald [:dao]]

(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?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Preloading for XUL documents seems reasonable to me. XUL already avoids incremental rendering.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Robert Longson [:longsonr]]

XUL is obsolete now.