1535391 - Create the ability to associate displayed resources to their request origins

Status: NEW

(Core :: Gecko Profiler, enhancement, P3)

Description

[Bas Schouten (:bas.schouten)]

Currently we have no easy way to understand when we are slow at loading images, exactly which requests lie at the source of those images being displayed, and what page activity triggered that request. Ideally the profiler would have a feature that would allow us to see a list of resources that are part of a certain frame, and where in JS or HTML/Style code those requests originated so that we can get an idea of where the source of a delay may be.

Comment 1

[Honza Bambas (:mayhemer)]

I think this is what Backtrack (BT) aims at. I've already implemented a drafty way to track back repaints of elements having DOM node id attribute. But tracking back can be pretty much generalized, we only need a unique enough identification for the ending point to go back from. The backtrack data is quite raw, but I already have facilitates to extract only the necessary information out of the whole path back to the source. I soon want to plan integrating the functionality (or at least some parts of it as a start) into the profiler.

Comment 2

[Bas Schouten (:bas.schouten)]

(In reply to Honza Bambas (:mayhemer) from comment #1)

I think this is what Backtrack (BT) aims at. I've already implemented a drafty way to track back repaints of elements having DOM node id attribute. But tracking back can be pretty much generalized, we only need a unique enough identification for the ending point to go back from. The backtrack data is quite raw, but I already have facilitates to extract only the necessary information out of the whole path back to the source. I soon want to plan integrating the functionality (or at least some parts of it as a start) into the profiler.

I would like this to be in the gecko profiler, note also that this doesn't need to do nearly as much as backtrack does. All I want is to be able to see which requests tie to which frame. Which should be relatively simple.

Comment 3

[Greg Tatum [:gregtatum]]

Do we just need a stacktrace for the start network marker to accomplish this? It sounds like there would be follow-up UI work on the profiler to support filtering by this information.

Comment 4

[Bas Schouten (:bas.schouten)]

(In reply to Greg Tatum [:gregtatum] from comment #3)

Do we just need a stacktrace for the start network marker to accomplish this? It sounds like there would be follow-up UI work on the profiler to support filtering by this information.

Hmm, no, we'd need to track which composite the 'result' of that network request becomes part of as well, that shouldn't be too difficult, but it is a little more involved. The result of that network request might be an image, which we then proceed to decode off the main thread, and may yet arrive in another composite again, Markus may have an idea on how to do this already, otherwise we'll have to come up with something.