Closed
Bug 1062826
Opened 11 years ago
Closed 11 years ago
talos glterrain regression due to disabling datasubmission policy notifications for Talos
Categories
(Firefox Health Report Graveyard :: Client: Desktop, defect)
Firefox Health Report Graveyard
Client: Desktop
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: gfritzsche, Assigned: gfritzsche)
References
Details
(Keywords: perf, regression, Whiteboard: [talos_regression])
(In reply to Georg Fritzsche [:gfritzsche] from bug 1060460, comment #15)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/7a721388e46b
Hm, so this strangely seems to have triggered "WEBGL Terrain" regressions:
http://graphs.mozilla.org/graph.html#tests=[[325,131,35]]&sel=1409656834000,1409829634000&displayrange=7&datatype=running
http://graphs.mozilla.org/graph.html#tests=[[325,131,33]]&sel=1409656425000,1409829225000&displayrange=7&datatype=running
http://graphs.mozilla.org/graph.html#tests=[[325,131,31]]&sel=1409658214000,1409831014000&displayrange=7&datatype=running
http://graphs.mozilla.org/graph.html#tests=[[325,131,37]]&sel=1409658219000,1409831019000&displayrange=7&datatype=running
Those seem to look real, right?
I don't really see other possible causes except maybe the healthreporter being instantiated at a different time, so i'll have to check more into this tomorrow - jmaher pointed me to how to actually run tg1 locally.
Flags: firefox-backlog+
Comment 1•11 years ago
|
||
The regression does seem real at the graph. The question is IMO: did you correctly identify the cause?
Also, I don't think the title is correct. TART and glterrain are two completely unrelated talos tests.
Even if you did identify the cause correctly, then the title should be "talos glterrain regression due to disabling datasubmission policy notifications for Talos", right? Unless I'm missing something, I don't see how glterrain could regress due to anything in TART.
![]() |
Assignee | |
Updated•11 years ago
|
Summary: TART regressions in WEBGL Terrain from bug 862563 → talos glterrain regression due to disabling datasubmission policy notifications for Talos
Updated•11 years ago
|
Keywords: perf,
regression
Whiteboard: [talos_regression]
Comment 2•11 years ago
|
||
Quoting myself from IRC:
<avih> gfritzsche: the thing with glterrain is that it's a webgl test, and the bigger the area it has to render, the slower the performance is. my suspicion is that because the notification takes some window area, webgl rendered to a smaller area and that's why when you removed the notification it has to render to a bigger area and so the performance degrade. but we should be able to see the invert improvement when the notification was added.
So the task now is to find evidence that adding the notification improved the glterrain numbers, and that removing it restored the numbers to their prior values (the latter is this bug, the former is needed for confirmation).
If we can do that, all is good and no further action will be required.
![]() |
Assignee | |
Comment 3•11 years ago
|
||
The push to inbound, 94ba78a42305, was here:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=2d8fba7b3e14
All 4 regressing charts above show a comparable improvement at that push, so closing this per Avis input.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Updated•11 years ago
|
Flags: qe-verify?
![]() |
Assignee | |
Updated•11 years ago
|
Flags: qe-verify? → qe-verify-
Resolution: WORKSFORME → FIXED
Updated•7 years ago
|
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•