Mouse hover response is slow in Nightly27.0a1 than Aurora26.a2

RESOLVED WORKSFORME

Status

()

Core
Layout
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: Alice0775 White, Unassigned)

Tracking

({perf, regression, reproducible})

27 Branch
x86_64
Windows 7
perf, regression, reproducible
Points:
---

Firefox Tracking Flags

(firefox26 unaffected, firefox27 affected, firefox28 affected)

Details

Attachments

(1 attachment, 1 obsolete attachment)

12.04 KB, application/x-zip-compressed
Details
(Reporter)

Description

4 years ago
Build Identifier:
http://hg.mozilla.org/mozilla-central/rev/21d97baadc05
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131022195201

Steps To Reproduce:
1. Open https://marketplace.firefox.com/ (NOTE. Browser will crash until landing Bug 928615)
2. Click "All Categories ^" to expand a list
3. Mouse move around the categories

Actual Results:
Mouse hover response is slow

Expected Results:
Mouse hover response should be instantly
(Reporter)

Updated

4 years ago
status-firefox26: --- → unaffected
status-firefox27: --- → affected
(Reporter)

Comment 1

4 years ago
Created attachment 820960 [details]
semi-reduced.zip,  open index.html
(Reporter)

Comment 2

4 years ago
Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/855da6d8a327
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131017044622
Bad:
http://hg.mozilla.org/mozilla-central/rev/2def80d5a106
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131018023712
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=855da6d8a327&tochange=2def80d5a106


Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/9c8ab7e9ae41
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131017025216
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/45d9e6cd3473
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131017030414
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9c8ab7e9ae41&tochange=45d9e6cd3473

regressed by:
a417424f9213	Robert O'Callahan — Bug 923193. Make transform-origin on SVG elements use the SVG bbox as the reference rectangle. r=heycam
Blocks: 923193
tracking-firefox27: --- → ?
Keywords: regression
(Reporter)

Updated

4 years ago
Component: General → Layout
(Reporter)

Comment 3

4 years ago
Created attachment 820974 [details]
semi-reduced.zip,  open index.html
Attachment #820960 - Attachment is obsolete: true
Needinfo on :roc to help give an assessment of impact here. Do we think this will be a critical issue and we would see this on other websites as well ?
Flags: needinfo?(roc)
(Reporter)

Comment 5

4 years ago
FYI, unfortunately, Bug 929021 cset 75ee2a0bc5d3 does not fix this problem.
I'm not sure that I can reproduce this.
Flags: needinfo?(roc)
I verified that with the testcase in comment #3, and bug 929021 fixed, we don't hit nsDisplayTransform::GetFrameBoundsForTransform at all. I don't see anything else in the patch for 923193 that could hurt performance in any significant way.
Since I have no idea what the problem is, it's hard to assess its impact.
(Reporter)

Comment 9

4 years ago
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)
> I verified that with the testcase in comment #3, and bug 929021 fixed, we
> don't hit nsDisplayTransform::GetFrameBoundsForTransform at all. I don't see
> anything else in the patch for 923193 that could hurt performance in any
> significant way.

I can still see the performance regression in 
http://hg.mozilla.org/mozilla-central/rev/2f2a45f04e7c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 ID:20131025100746

So, Bug 929021 changes nothing.

And I am confidence the a417424f9213 trrigger the performance regression.

Note, 
This regression does not happen if HWA disabled.
AND, this seems do not happen on Linux.
(Reporter)

Comment 10

4 years ago
s/trrigger/trigger/
(Reporter)

Comment 11

4 years ago
STR
0. Start Firefox with HWA on
1. Open index.html (attachment 820974 [details]),  
2. Mouse quickly move UP/DOWN
  --- observe highlight

Actual Results:
  The highlight is late for the movement of the mouse and follows it.

Expected Results:
  The highlight should react to the movement of the mouse immediately.
(Reporter)

Comment 12

4 years ago
Screen capture
http://youtu.be/ejrakVZUXPo
(Reporter)

Comment 13

4 years ago
FYI
Setting gfx.content.azure.enabled = false fixes the performance regression
Also adding qawanted to help reproduce.
Keywords: qawanted
The semi reduced test case easily reproduces the problem.

It is a Win only regression.  Mac works fine.
status-firefox28: --- → affected
tracking-firefox28: --- → ?
Keywords: qawanted → reproducible
Now we have a test case do you have time to investigate and look further
Flags: needinfo?(roc)
I backed out bug 923193 and all related patches. Is this fixed now?
Flags: needinfo?(roc)
(Reporter)

Comment 18

4 years ago
I cannot reproduce the problem with attachment 820974 [details] and URL anymore in latest m-c tinderbox build.

http://hg.mozilla.org/mozilla-central/rev/581d180a37f3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 ID:20131111161638

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
tracking-firefox27: ? → ---
tracking-firefox28: ? → ---
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.