Bug 32636

Summary: Web Inspector: Show direction of function calls in CPU profiles
Product: WebKit Reporter: Mikhail Naganov <mnaganov>
Component: Web Inspector (Deprecated)Assignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: burg, bweinstein, joepeck, keishi, pfeldman, pmuellr, rik
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
UI mock
none
An example of CPU profile in YourKit Java profiler none

Description Mikhail Naganov 2009-12-16 15:09:55 PST
Created attachment 45019 [details]
UI mock

Right now when looking at a CPU profile the direction calls isn't obvious -- it can only be determined by looking at the status bar. My proposal is to show direction of calls explicitly by using arrow icons between a triangle glyph and function name (as drive / folder / file icons in Finder). The UI mock is attached.
Comment 1 Timothy Hatcher 2009-12-16 15:40:41 PST
I don't think this is needed. All the profiling tools on OS X don't have these indicators and have modes for top down or bottom up. Once you know the mode you are in you know what you are looking at. These just get in the way, IMHO.
Comment 2 Mikhail Naganov 2009-12-17 05:02:13 PST
Created attachment 45056 [details]
An example of CPU profile in YourKit Java profiler

Tim, your statement that there is no profiler for OS X that uses arrows isn't completely true. This is a screenshot of YourKit profiler which has them.

I agree that arrows may look redundant. But I think this is good redundancy that helps understanding for novices. To reduce clutter, opacity of these arrows can be decreased even more, so they will be perceived as a background, being ignored by people who don't need them, but still giving a hint for novices.
Comment 3 Timothy Hatcher 2009-12-17 09:30:46 PST
I was just referencing the tools Apple ships with Xcode.
Comment 4 Pavel Feldman 2009-12-17 09:44:14 PST
(In reply to comment #3)
> I was just referencing the tools Apple ships with Xcode.

I am lost, why are we talking about Apple Xcode tools? :)
Comment 5 Pavel Feldman 2009-12-17 09:46:09 PST
> I am lost, why are we talking about Apple Xcode tools? :)

Having said that, mock looks ugly
Comment 6 Mikhail Naganov 2009-12-17 09:51:41 PST
(In reply to comment #5)
> > I am lost, why are we talking about Apple Xcode tools? :)
> 
> Having said that, mock looks ugly

Thanks for your support. I must admit, I don't like the clutter introduced by those arrows, too. I will think about how to display this information more organically.
Comment 7 Joseph Pecoraro 2009-12-17 10:18:53 PST
> I agree that arrows may look redundant. But I think this is good redundancy
> that helps understanding for novices. To reduce clutter, opacity of these
> arrows can be decreased even more, so they will be perceived as a background,
> being ignored by people who don't need them, but still giving a hint for
> novices.

> I don't like the clutter introduced by those arrows, too. I will think about
> how to display this information more organically.

I won't vote either way yet, but I'll certainly say that the first time I saw this I liked the idea. Looking at the "YourKit" profiler, it does look like too many arrows creates too much clutter.
Comment 8 Timothy Hatcher 2009-12-17 10:19:18 PST
What are the dotted outline arrows vs the solid ones in YourKit?

I guess one part that bugs me about this, is the text is further indented. I wonder if there is a way to make the disclosure arrow point the difrection and not take extra space (and not look stupid.)

I'll play in photoshop for a bit, stay tuned.
Comment 9 Timothy Hatcher 2009-12-17 10:20:58 PST
(In reply to comment #7)
> Looking at the "YourKit" profiler, it does look like too
> many arrows creates too much clutter.

I tend to agree. But the dotted arrows mello it out more. Imagine if they were all solid. That is why I asked what the difference was.
Comment 10 Timothy Hatcher 2009-12-17 10:22:47 PST
I think we would want a different arrow for when a node is collapsed or has no children. So it does not point down, it points down and turns to point right (a curved arrow.)
Comment 11 Timothy Hatcher 2009-12-17 10:28:41 PST
What if the direction of flow only showed up when hovering a function. That would give you a clear path (highlighting the ancestor rows.) Right now it is hard to know who called who when there are many siblings. Fading out the siblings and showing the ancestors with a direction might be cool, and tastful and not cluttered.
Comment 12 Mikhail Naganov 2009-12-17 12:59:43 PST
(In reply to comment #9)
> (In reply to comment #7)
> > Looking at the "YourKit" profiler, it does look like too
> > many arrows creates too much clutter.
> 
> I tend to agree. But the dotted arrows mello it out more. Imagine if they were
> all solid. That is why I asked what the difference was.

As far as I see, they use dotted arrows for non-application code (libraries, etc), helping user to focus on the code that she can change.
Comment 13 Mikhail Naganov 2009-12-17 13:02:55 PST
(In reply to comment #11)
> What if the direction of flow only showed up when hovering a function. That
> would give you a clear path (highlighting the ancestor rows.) Right now it is
> hard to know who called who when there are many siblings. Fading out the
> siblings and showing the ancestors with a direction might be cool, and tastful
> and not cluttered.

Yes, I had the same idea while riding back home. My thought was "how to make this hint easily accessible, but without showing it everywhere?", so displaying it on hover was kinda logical choice.

I can sketch up a mock, too. I love to play a designer role ;)
Comment 14 Timothy Hatcher 2009-12-17 13:24:42 PST
It also could work for the selected node too. Sometimes hover is too twitchy. Working for the selected node would keep keyworad users happy.
Comment 15 Timothy Hatcher 2009-12-17 13:25:10 PST
(In reply to comment #14)
> It also could work for the selected node too. Sometimes hover is too twitchy.
> Working for the selected node would keep keyworad users happy.

I meant "keyboard users".
Comment 16 Mikhail Naganov 2010-01-13 02:50:21 PST
(In reply to comment #14)
> It also could work for the selected node too. Sometimes hover is too twitchy.
> Working for the selected node would keep keyworad users happy.

So here is a screencast demo: http://screencast.com/t/MTMyZWZkNDE

Please don't mind the look of arrows, I know they are ugly. What is your overall feeling about this?

If we would be implementing this, something must be done to the way of how tree triangles are rendered. Currently they are added using ::before modifier. As there can be no two 'before's (one for triangle and one for arrow), I think triangles would need to be displayed as inline blocks.
Comment 17 Timothy Hatcher 2010-01-13 04:53:50 PST
This looks OK, the arrow isn't that bad (but is is 4 am here and I have blury vision.)

I did expect to see a whole chain of arrow on all the ancestors, not just the hovered one. Otherwise I don't see much benifit/difference. And/Or dim out the non-ancestor rows.
Comment 18 Brian Burg 2014-12-11 17:10:54 PST
We don't have top-down/bottom-up UI anymore :| (I would have voted for the arrows)