Closed
Bug 1356663
Opened 8 years ago
Closed 8 years ago
3.5ms uninterruptible reflow at _calcMouseTargetRect@chrome://browser/content/tabbrowser.xml:7763:27 when the status text changes
Categories
(Firefox :: Tabbed Browser, defect, P1)
Firefox
Tabbed Browser
Tracking
()
People
(Reporter: mconley, Assigned: dao)
References
(Blocks 1 open bug)
Details
(Whiteboard: [ohnoreflow][photon-performance])
Attachments
(1 file)
Here's the stack:
_calcMouseTargetRect@chrome://browser/content/tabbrowser.xml:7763:27
set_label@chrome://browser/content/tabbrowser.xml:7713:13
updateStatusField@chrome://browser/content/browser.js:4513:7
_showDelayed/this._timer<@chrome://browser/content/browser.js:4922:7
Assignee | ||
Updated•8 years ago
|
Flags: needinfo?(dao+bmo)
Updated•8 years ago
|
Flags: qe-verify?
Priority: -- → P2
Assignee | ||
Comment 1•8 years ago
|
||
I think this is basically unavoidable. We can call _calcMouseTargetRect more lazily in getMouseTargetRect, but this will only make a difference for the resize event handler. With the stack from comment 0, MousePosTracker will immediately call getMouseTargetRect anyway (it has to).
Flags: needinfo?(dao+bmo)
Comment hidden (mozreview-request) |
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED
Assignee | ||
Updated•8 years ago
|
Flags: qe-verify? → qe-verify-
Updated•8 years ago
|
Priority: P2 → P1
Comment 3•8 years ago
|
||
mozreview-review |
Comment on attachment 8858607 [details]
Bug 1356663 - Calculate the status panel's mouse target rectangle lazily in getMouseTargetRect.
https://reviewboard.mozilla.org/r/130604/#review133854
r=me because this is an improvement over the current state, but I think we can do better.
How much effort would it be to add a listener for a bigger target that would have the height of the statusbar panel (we can get this value without sync flush, right?) and the full width of the content area? And then only if that bigger area is entered by the mouse, compute the exact size of the rect we care about and set another listener for that specific area. MousePosTracker may need a few changes to make this work (eg. to notify immediately a listener for an area that is already hovered at the time the listener is added).
Attachment #8858607 -
Flags: review?(florian) → review+
Pushed by dgottwald@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c5bdfc3ba44d
Calculate the status panel's mouse target rectangle lazily in getMouseTargetRect. r=florian
Assignee | ||
Comment 5•8 years ago
|
||
(In reply to Florian Quèze [:florian] [:flo] from comment #3)
> Comment on attachment 8858607 [details]
> Bug 1356663 - Calculate the status panel's mouse target rectangle lazily in
> getMouseTargetRect.
>
> https://reviewboard.mozilla.org/r/130604/#review133854
>
> r=me because this is an improvement over the current state, but I think we
> can do better.
>
> How much effort would it be to add a listener for a bigger target that would
> have the height of the statusbar panel (we can get this value without sync
> flush, right?)
Actually no, there's no parent or sibling node with the same height as the statuspanel is position:fixed.
Comment 6•8 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #5)
> > How much effort would it be to add a listener for a bigger target that would
> > have the height of the statusbar panel (we can get this value without sync
> > flush, right?)
>
> Actually no, there's no parent or sibling node with the same height as the
> statuspanel is position:fixed.
Could we remember that height the first time we get it? And maybe get it using getBoundsWithoutFlushing (and fallback to flushing only if the value we got from getBoundsWithoutFlushing is 0) ? This height doesn't change, right?
Comment 7•8 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox55:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
Updated•8 years ago
|
Iteration: --- → 55.4 - May 1
Updated•8 years ago
|
Summary: 3.5ms uninterruptible reflow at _calcMouseTargetRect@chrome://browser/content/tabbrowser.xml:7763:27 → 3.5ms uninterruptible reflow at _calcMouseTargetRect@chrome://browser/content/tabbrowser.xml:7763:27 when the status text changes
Assignee | ||
Updated•8 years ago
|
Updated•8 years ago
|
No longer blocks: photon-performance-triage
Updated•8 years ago
|
Blocks: photon-performance-triage
Updated•3 years ago
|
Performance Impact: --- → ?
Whiteboard: [ohnoreflow][qf][photon-performance] → [ohnoreflow][photon-performance]
You need to log in
before you can comment on or make changes to this bug.
Description
•