During initial page load, HTML is parsed off main thread, but has an impact on perceived page load performance. Images are decoded lazily off main thread, but have an impact on perceived scrolling performance / responsiveness. Compositing happens off main thread. Etc... We should support adding timeline markers from other threads. Will need solutions for: * At the platform level, determining whether devtools is recording whatever tab(s) this operation is associated with (and how to figure out which tab(s) it is associated with in general, because we don't have a docshell). We don't want the overhead of adding markers when devtools isn't recording. * At the platform level, associating a marker with its thread of origin. I don't think this is going to be too bad. * At the UI level, rendering markers for each thread separately. Tabs? Different rows (like Chrome does, when in non-main-thread mode)? Something?

Copying Tom's coment from the wiki page here for posterity. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First, right now when a marker object is created, it acquires the time from the docshell. In docshell/base/TimelineMarker.cpp: TimelineMarker::TimelineMarker(nsDocShell* aDocShell, const char* aName, TracingMetadata aMetaData) [...] aDocShell->Now(&mTime); Now, I think nsDocShell::Now is actually thread-safe. However, I would probably move the logic into TimelineMarker itself and avoid the need to have a docshell at TimelineMarker creation. The code was written this way mostly for historical reasons, but also perhaps to make sure that the timeline epoch is dealt with in a single place. At this point you could make a new TimelineMarker object on any thread. So then the next step is to ship it to the main thread. Basically I'd make a new nsIRunnable that holds the TimelineMarker object, and use NS_DispatchToMainThread. This runnable would call nsDocShell::AddProfileTimelineMarker when it ran. This last step is the trickiest -- you have to pick which docshell to notify. I don't know of a generic way to do this; it's been the trickiest part of the patches I worked on. ('''Note from Paul''': depending on the type of thread, we might register these markers at the global level. For example, it doesn't make sense to attach markers from the compositor thread to a docshell. It's not the case to network threads though). Because we add the start and stop-markers to the docshell separately, it's simple to add a start marker from one thread and an end marker from another thread; or whatever you like.

(In reply to Nick Fitzgerald [:fitzgen] from comment #0) > * At the UI level, rendering markers for each thread separately. Tabs? > Different rows (like Chrome does, when in non-main-thread mode)? Something? Probably different rows is better. Tabs wouldn't make sense for something like image decoding where we may have several threads all working on the same task.

Have this now.