162234 - throbber uri is parsed too often

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[Bradley Baetz (:bbaetz)]

I don't know if this is throbber-specific, or if it happens for all css backgrounds.

While looking into another bug, I noticed that we seem to parse the
throbber url (chrome://communicator/skin/toolbar/prtb-bg-noline.gif) an
awful lot.

a) We parse it three times before a window even shows
b) Switching tabs parses it 5 times
c) Moving the mouse over or off any active toolbar button
(back/forward/reload) parses it once (why?)
d) A cached load of www.google.com parses it 10 times, and un uncache load
22
e) A load of http://localhost/ parses it 5 times
f) 85 times for a fresh load of http://slashdot.org/

Numbers are approximate, of course.

The image isn't loaded after the first time, because nsImageLoader.cpp (in
layout) does some caching. Parsing the url isn't that expensive, but
couldn't something cache this somewhere? Or maybe not even try to load the
image if if the url hasn't changed?

The stack down from the NewURI call is:

nsIOService::NewURI(nsACString const &, char const *, nsIURI *, nsIURI
**)+0x000001E8 [/home/bbaetz/src/objdir/dist/bin/components/libnecko.so
+0x00067FD0]
nsPresContext::LoadImage(nsString const &, nsIFrame *, imgIRequest
**)+0x0000045F [/home/bbaetz/src/objdir/dist/bin/components/libgklayout.so
+0x0030652F]
nsCSSRendering::PaintBackgroundWithSC(nsIPresContext *,
nsIRenderingContext &, nsIFrame *, nsRect const &, nsRect const &,
nsStyleBackground const &, nsStyleBorder const &, int, int,
int)+0x00000532
[/home/bbaetz/src/objdir/dist/bin/components/libgklayout.so +0x00243BC2]  
nsCSSRendering::PaintBackground(nsIPresContext *, nsIRenderingContext &,
nsIFrame *, nsRect const &, nsRect const &, nsStyleBorder const &, int,
int, int)+0x000003B9
[/home/bbaetz/src/objdir/dist/bin/components/libgklayout.so +0x00243241]

And then lots of recursion for nsBoxFrame::Paint/PaintChild/PaintChildren

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think I have a bug somewhere on storing nsIURI pointers in the CSS stylesheet
backend, although I might not.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Looks like bug 128985 to me...

Comment 3

[Bradley Baetz (:bbaetz)]

No, thats a differnet use case, and is for http. Althjough every character on
the url bar does cause another parse of the throbber url.

/me wonders why typing on the urlbar/hovering over the reload button way to
touch anything to do with the throbber, anyway.

The patch there looks like it belongs in bug 113173, though.

Comment 4

[Doug Turner (:dougt)]

I was probably cc'ed on this cause I was collected some data last week on this.

These are the top URL's created at start up via the io service:

95
file:///C:/Documents%20and%20Settings/dougt/Application%20Data/Mozilla/Profiles/DEBUG/etnwnwtt.slt/localstore.rdf
74	resource:/chrome/classic.jar
27	resource:/chrome/toolkit.jar
17	resource:/chrome/en-US.jar
8
file:///C:/builds/trunk/mozilla/dist/bin/chrome/overlayinfo/messenger/content/overlays.rdf


After overlays.rdf, the list tapers off.


During redraw, image urls slam the IO service ask for a new uri.  Maybe the
nsPresContext should cache the top url's it encounters or use dbaron's
approach... or maybe we should fix up the chrome protocol to do this?  thoughts?

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Should be fixed by the checkin to bug 113173.