WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
101749
Web Inspector: Timeline: enhance short-records filter.
https://bugs.webkit.org/show_bug.cgi?id=101749
Summary
Web Inspector: Timeline: enhance short-records filter.
eustas.bug
Reported
2012-11-09 05:53:59 PST
Currently filter could be "on" (accepting records longer than 15ms) or "off" (accepting all records). Adding some options between 0ms and 15ms will make this feature much more useful.
Attachments
Screenshot1
(33.86 KB, image/png)
2012-11-09 06:03 PST
,
eustas.bug
no flags
Details
Screenshot2
(30.73 KB, image/png)
2012-11-09 06:03 PST
,
eustas.bug
no flags
Details
Patch
(18.94 KB, patch)
2012-11-09 07:04 PST
,
eustas.bug
no flags
Details
Formatted Diff
Diff
Patch
(18.05 KB, patch)
2012-11-15 07:17 PST
,
eustas.bug
no flags
Details
Formatted Diff
Diff
Filter button as select box
(28.99 KB, image/png)
2012-11-23 02:09 PST
,
dubroy
no flags
Details
Patch
(20.02 KB, patch)
2012-12-17 01:40 PST
,
Eugene Klyuchnikov
pfeldman
: review+
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
eustas.bug
Comment 1
2012-11-09 06:03:20 PST
Created
attachment 173285
[details]
Screenshot1
eustas.bug
Comment 2
2012-11-09 06:03:39 PST
Created
attachment 173286
[details]
Screenshot2
eustas.bug
Comment 3
2012-11-09 07:04:52 PST
Created
attachment 173300
[details]
Patch
WebKit Review Bot
Comment 4
2012-11-09 13:51:32 PST
Comment on
attachment 173300
[details]
Patch
Attachment 173300
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/14794078
Pavel Feldman
Comment 5
2012-11-11 23:01:58 PST
Comment on
attachment 173300
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=173300&action=review
> Source/WebCore/ChangeLog:10 > + will make this feature much more useful.
What is this assessment based on?
> Source/WebCore/inspector/front-end/ProfilesPanel.js:1028 > this.profileViewStatusBarItemsContainer.style.left = Math.max(minFloatingStatusBarItemsOffset, this.splitView.sidebarWidth()) + "px";
This will result as a warning on your timeline, no? You are measuring totalOffsetLeft and applying it to the style. Is that intended?
> Source/WebCore/inspector/front-end/StatusBarButton.js:32 > + * @typedef {{element: !Element, disabled: boolean}}
We don't use typedefs, ui components are compiled together.
> Source/WebCore/inspector/front-end/StatusBarButton.js:286 > + set disabled(value)
Please do not create new getters / setters. They are not compiler friendly.
eustas.bug
Comment 6
2012-11-11 23:36:39 PST
Comment on
attachment 173300
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=173300&action=review
>> Source/WebCore/ChangeLog:10 >> + will make this feature much more useful. > > What is this assessment based on?
This assessment is based on experience analyzing WebGL apps. Typically each frame is 8-30 ms long. But it may contain a ton of short calls to graphics subsystem. It is hard to find most significant (>=1ms) among them.
>> Source/WebCore/inspector/front-end/ProfilesPanel.js:1028 >> this.profileViewStatusBarItemsContainer.style.left = Math.max(minFloatingStatusBarItemsOffset, this.splitView.sidebarWidth()) + "px"; > > This will result as a warning on your timeline, no? You are measuring totalOffsetLeft and applying it to the style. Is that intended?
totalOffestLeft had been being measured before this patch. This change make it possible to add status bar items of unspecified width as well as make changes of style easier. Results of measuring are intentionally applied to style, because there is no CSS-friendly way to make this position binding. Perhaps, we could throw away this logic, because it doesn't make much sense to move additional controls alongside split-view pane.
>> Source/WebCore/inspector/front-end/StatusBarButton.js:32 >> + * @typedef {{element: !Element, disabled: boolean}} > > We don't use typedefs, ui components are compiled together.
I would like to use interface, but getters made this impossible.
>> Source/WebCore/inspector/front-end/StatusBarButton.js:286 >> + set disabled(value) > > Please do not create new getters / setters. They are not compiler friendly.
Yes, I know. But this getter was added because of StatusBarButton one's. I would like to remove both, if you do not mind.
eustas.bug
Comment 7
2012-11-15 07:08:10 PST
Comment on
attachment 173300
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=173300&action=review
>>> Source/WebCore/inspector/front-end/StatusBarButton.js:32 >>> + * @typedef {{element: !Element, disabled: boolean}} >> >> We don't use typedefs, ui components are compiled together. > > I would like to use interface, but getters made this impossible.
Fixed.
>>> Source/WebCore/inspector/front-end/StatusBarButton.js:286 >>> + set disabled(value) >> >> Please do not create new getters / setters. They are not compiler friendly. > > Yes, I know. But this getter was added because of StatusBarButton one's. > I would like to remove both, if you do not mind.
Removed
eustas.bug
Comment 8
2012-11-15 07:17:09 PST
Created
attachment 174435
[details]
Patch
dubroy
Comment 9
2012-11-23 02:05:01 PST
Some comments on the UI: - Select box options should not have tooltips (as shown in Screenshot1). If you want to communicate "Show all records", just make the option say "Show all records". Likewise for the other options. - On the subject of tooltips, it's confusing when the tooltip says the inverse of what the control says: "Show records >= 15ms" vs. "Hide records < 15ms". It's not communicating extra information. What about keeping the existing filter button, but just making it act like a select box? I will attach a screenshot.
dubroy
Comment 10
2012-11-23 02:09:47 PST
Created
attachment 175756
[details]
Filter button as select box
Pavel Feldman
Comment 11
2012-12-14 00:26:50 PST
Comment on
attachment 174435
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=174435&action=review
Looks almost good. I don't think you should remove the 31* piece from non-timeline panels.
> Source/WebCore/inspector/front-end/ProfilesPanel.js:1027 > + var minFloatingStatusBarItemsOffset = lastItemElement.totalOffsetLeft() + lastItemElement.offsetWidth;
This will cause force layout.
Eugene Klyuchnikov
Comment 12
2012-12-17 01:39:11 PST
(In reply to
comment #11
)
> (From update of
attachment 174435
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=174435&action=review
> > Looks almost good. I don't think you should remove the 31* piece from non-timeline panels. > > > Source/WebCore/inspector/front-end/ProfilesPanel.js:1027 > > + var minFloatingStatusBarItemsOffset = lastItemElement.totalOffsetLeft() + lastItemElement.offsetWidth; > > This will cause force layout.
Actually, this won't cause additional re-layouts. I've modified patch a bit to reduce query/set clutter.
Eugene Klyuchnikov
Comment 13
2012-12-17 01:40:17 PST
Created
attachment 179704
[details]
Patch
Andrey Kosyakov
Comment 14
2012-12-20 04:45:22 PST
Committed
r138244
: <
http://trac.webkit.org/changeset/138244
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug