951418 - Port trace_viewer to gecko

Status: RESOLVED FIXED

(Core :: Gecko Profiler, defect)

Description

[Benoit Girard (:BenWa)]

We'd like to get a 'flamegraph' view for the profiler. Chrome uses trace_viewer which I believe we could reuse. The problem is that they use several webkit specific features and it's very difficult to port. If we complete the port we can reuse the same trace_viewer tool that people are already familiar with using.

The repo can be found here:
http://code.google.com/p/trace-viewer/

Note that the head revision using createShadowRoot which isn't well supported in Gecko. However revision 200 has all the features we need for now and doesn't use createShadowRoot.

The first set of problems is that they use webkitRequestAnimationFrame and the chrome js object. This is easy to fix. The hard problem is that they use flex-box and input features we don't support (like window.event). I tried doing this port myself but I quickly hit a wall.

The goal is to get <repo>/src/interactive_tests.html running as well in Firefox as in Chrome then we can integrate the view in the profiler UI.

Comment 1

[(no longer active)]

(In reply to Benoit Girard (:BenWa) from comment #0)
> Note that the head revision using createShadowRoot which isn't well
> supported in Gecko. However revision 200 has all the features we need for
> now and doesn't use createShadowRoot.

If this remains an issue, try http://www.polymer-project.org/

> The first set of problems is that they use webkitRequestAnimationFrame and
> the chrome js object.

Is that window.chrome?  What do they access off of that?

> This is easy to fix. The hard problem is that they use
> flex-box and input features we don't support (like window.event). I tried
> doing this port myself but I quickly hit a wall.

Hmm, window.event _should_ be replaceable with the event object that we pass to the event handler.

Comment 2

[Benoit Girard (:BenWa)]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #1)
> (In reply to Benoit Girard (:BenWa) from comment #0)
> > Note that the head revision using createShadowRoot which isn't well
> > supported in Gecko. However revision 200 has all the features we need for
> > now and doesn't use createShadowRoot.
> 
> If this remains an issue, try http://www.polymer-project.org/
> 
> > The first set of problems is that they use webkitRequestAnimationFrame and
> > the chrome js object.
> 
> Is that window.chrome?  What do they access off of that?

nothing that we need, I added window.chrome = {} and that fixed that issue.
> 
> > This is easy to fix. The hard problem is that they use
> > flex-box and input features we don't support (like window.event). I tried
> > doing this port myself but I quickly hit a wall.
> 
> Hmm, window.event _should_ be replaceable with the event object that we pass
> to the event handler.

Yes that also works.

The real problem is when I replace everything with all the webkit stuff with either -moz- or the non prefix version (as applicable) it doesn't size the elements properly.

Comment 3

[(no longer active)]

(In reply to comment #2)
> (In reply to :Ehsan Akhgari (needinfo? me!) from comment #1)
> > (In reply to Benoit Girard (:BenWa) from comment #0)
> > > Note that the head revision using createShadowRoot which isn't well
> > > supported in Gecko. However revision 200 has all the features we need for
> > > now and doesn't use createShadowRoot.
> > 
> > If this remains an issue, try http://www.polymer-project.org/
> > 
> > > The first set of problems is that they use webkitRequestAnimationFrame and
> > > the chrome js object.
> > 
> > Is that window.chrome?  What do they access off of that?
> 
> nothing that we need, I added window.chrome = {} and that fixed that issue.
> > 
> > > This is easy to fix. The hard problem is that they use
> > > flex-box and input features we don't support (like window.event). I tried
> > > doing this port myself but I quickly hit a wall.
> > 
> > Hmm, window.event _should_ be replaceable with the event object that we pass
> > to the event handler.
> 
> Yes that also works.
> 
> The real problem is when I replace everything with all the webkit stuff with
> either -moz- or the non prefix version (as applicable) it doesn't size the
> elements properly.

I'd ask dholbert about any possible flexbox issues.

Comment 4

[Benoit Girard (:BenWa)]

I asked dholbert for some help and made some progress tonight. There's only one remain 'big' issue and it's 2 pixel spacing only in firefox that I can't find where it's coming and how to remove it.

Comment 5

[Jerry Shih[:jerry] (UTC+8) (inactive)]

Attachment: systrace_firefox.png

current result for systrace on firefox

Comment 6

[Benoit Girard (:BenWa)]

Are we porting from the trace-viewer repo https://code.google.com/p/trace-viewer/? This way we can keep up with the latest improvements of trace-viewer.

Comment 7

[Jerry Shih[:jerry] (UTC+8) (inactive)]

No, I just use the latest systrace tool in android sdk(trace viewer reversion 775).
I will try the new one.

Comment 8

[Steve Fink [:sfink] [:s:]]

Stumbled across this bug. CC'ing Greg Tatum, who is working on something like this.

Comment 9

[Greg Tatum [:gregtatum]]

Oh cool. Work is progressing on github here: https://github.com/devtools-html/perf.html/issues/85

The terminology I'm using is that the tab is the Timeline view, but will have various reports including a time-based flame chart. There will be additional reports like marker information, and whatever else we cook up.

Comment 10

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

We've had a flame graph on profiler.firefox.com for a while now, so I'll mark this old bug fixed.