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
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
Created attachment 820974 [details] semi-reduced.zip, open index.html
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 ?
FYI, unfortunately, Bug 929021 cset 75ee2a0bc5d3 does not fix this problem.
I'm not sure that I can reproduce this.
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.
(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.
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.
Screen capture http://youtu.be/ejrakVZUXPo
FYI Setting gfx.content.azure.enabled = false fixes the performance regression
Also adding qawanted to help reproduce.
The semi reduced test case easily reproduces the problem. It is a Win only regression. Mac works fine.
Now we have a test case do you have time to investigate and look further
I backed out bug 923193 and all related patches. Is this fixed now?
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