performance.mark and measure will be widely supported as W3C User Timing[1] Spec. Furthermore, performance.measure can provide a start to end timing, according to this, user can choose region they care in overview pane easily if we draw measure on timeline. It should be a supplement of console.timeStamp & console.markTimeline. Reasonable? :) [1] http://www.w3.org/TR/2012/CR-user-timing-20120726/
Could you explain why we need another method of marking the timeline? Also, note that console.time and timeEnd allows selecting a region on the timeline today.
(In reply to comment #1) > Could you explain why we need another method of marking the timeline? Also, note that console.time and timeEnd allows selecting a region on the timeline today. I.e. I think they make sense wherever rest of the performance API is visualized. Otherwise it will be hard for the developer to find correlation between these signals and the other ones originating from the inspector instrumentation. Like timeline has been using wall clock until recently. Alternatively, we could deprecate console's time methods and make sure performance API is aligned with the inspector data. That might require re-implementing some of performance guts on top of inspector instrumentation. Tony, James, what do you think, could we try aligning them?
(In reply to comment #1) > Could you explain why we need another method of marking the timeline? Also, note that console.time and timeEnd allows selecting a region on the timeline today. Reason is people who use User Timing can also mark the timeline, and it’s not conflict with console.timeStamp I think.
(In reply to comment #1) > Could you explain why we need another method of marking the timeline? Also, note that console.time and timeEnd allows selecting a region on the timeline today. In addition, I tried console.time & console.timeEnd in chromium trunk today, only found timeEnd, and it is without mark names and not available via “Ctrl+F”, I will file this in another bug entry if it's agreed. :)
(In reply to comment #2) > (In reply to comment #1) > > Could you explain why we need another method of marking the timeline? Also, note that console.time and timeEnd allows selecting a region on the timeline today. > > I.e. I think they make sense wherever rest of the performance API is visualized. Otherwise it will be hard for the developer to find correlation between these signals and the other ones originating from the inspector instrumentation. Like timeline has been using wall clock until recently. What if wall clock adjusted during instrumentation? > > Alternatively, we could deprecate console's time methods and make sure performance API is aligned with the inspector data. That might require re-implementing some of performance guts on top of inspector instrumentation. Tony, James, what do you think, could we try aligning them? Encourage developer to use user timing to mark timeline as standard is reasonable, as standard. I guess re-implementing performance on top of inspector instrumentation is not a must if timing mechanism is aligned.
Closing as invalid, as this bug pertains to the old inspector UI and/or its tests. Please file a new bug (https://www.webkit.org/new-inspector-bug) if the bug/feature/issue is still relevant to WebKit trunk.