Open Bug 1416652 Opened 2 years ago Updated 4 months ago
Bad performance on running tsvgx talos suite
See  and  for the Comparison link in detail. They showed that tsvgx opt e10s in Linux x64 opt: 60.61% tsvgx opt e10s stylo_disabled in Linux x64 opt: 59.48% tsvgx opt e10s in Windows 10 x64 opt: 322.49% tsvgx opt e10s stylo_disabled in Windows 10 x64 opt: 288.54% : Comparison link on Linux x64 opt https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=226893bbeb3e&newProject=try&newRevision=624d8ef848c2d76eed6a2854e03e3c54950ffd12&framework=1 : Comparison link on Windows 10 x64 opt https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=e20b42426413&newProject=try&newRevision=ec5b6c878d2abaf1c98a5cdc1284fd38625f1822&framework=1
2 years ago
Whiteboard: [wr-mvp] → [wr-mvp] [gfx-noted]
Based on Bug 1416630 Comment 1, it still worse than disabling wr. I will still keep this open. linux64: tsvgx opt e10s: 73.65% tsvgx opt e10s stylo_disabled: 73.65% Windows 10 x64 opt: tsvgx opt e10s: 195.25% : https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=03107377dac6&newProject=try&newRevision=26095b988f06e8cb097118dd9ba051966fe9b195&framework=1 : https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=051d048108f2&newProject=try&newRevision=52ee54a2130bcea167e32308374a6ccd0d5950b4&framework=1
I think we should measure talos with non-blobimage for now, since blobimage haven't been turned on by default.
(In reply to Ethan Lin[:ethlin] from comment #2) > I think we should measure talos with non-blobimage for now, since blobimage > haven't been turned on by default. I tried to rebase with today's code base and created another comparison for tsvgx talos. It still worse than disabling wr. But even so, it becomes better when I measured it at the first time on 2017-11-12. linux64: 21.30% windows10-64: 49.53% linux64: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=27124062459e&newProject=try&newRevision=6344d84dbfeff7fb75aa6da33980b9cd119e56be&framework=1 windows10-64: https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=8cc7ccdb5c91&newProject=try&newRevision=6ca9d9eb44e5b2ac51c5ba5c6c7d6e049600d219&framework=1
From comment 1 and comment 3, svg fallback is 3 times better than svg with blob image on. I will lower the priority because we havn't turn blob image on by default. [WR with blob image on] linux64: tsvgx opt e10s: 73.65% Windows 10 x64: tsvgx opt e10s: 195.25% [WR with blob image off] linux64: 21.30% windows10-64: 49.53%
Assignee: ethlin → nobody
Status: ASSIGNED → NEW
Priority: P1 → P3
Whiteboard: [wr-mvp] [gfx-noted] → [wr-reserve] [gfx-noted]
No longer blocks: 1416635
https://treeherder.mozilla.org/perf.html#/graphs?series=autoland,1646629,1,1&series=autoland,1683595,1,1&series=autoland,1651299,1,1&series=autoland,1686440,1,1 Linux and Windows are both worse with WR enabled than disabled. Bumping to P1 for windows regression.
Duplicate of this bug: 1451203
Depends on: 1467169
As of bug 1476636/bug 1455422 landing, this got worse on both Linux and Windows.
We can't release this to the field, but we can let this ride to beta. However, we want to investigate and understand the bad perf numbers asap.
Priority: P1 → P2
Whiteboard: [wr-reserve] [gfx-noted] → [wr-reserve] [gfx-noted][needs-investigation]
I had a look at some of the subtests, and what we might be able to do to improve scores on them: hixie-001.xml: hixie-002.xml: Moves a circle around on top of a complex SVG image. Animation is done from JS, and modifies the cx/cy attributes on an SVG circle element. It also updates text at the bottom of the SVG show how many frames of the animation have been presented. Since we only use a single dirty rect, we end up invalidating the union of the new/old circle areas and the text, which is a pretty large area of the image. Switching to a region for dirty areas would help a lot here. We could also try teaching the grouping code to know to put the circle into a separate blob, but that's pretty complex FLB-like logic that we to avoid if possible. The second subtest is the same as the first, except the circle is partially transparent (using the fill-opacity attribute). hixie-003.xml: Regression is relatively minor, not investigated. hixie-004.xml: Adds scaled and transformed images to the scene each frame. Dirty rect covers most of the SVG most frame, and it doesn't look like we could do a whole lot better here. We add two images per frame, and currently we repaint tiles fully if they intersect the dirty rect, so on some frames have a dirty region, and dirty-per-tile might help. We could also try promoting simple SVG images to real WebRender display items, and composite them on the GPU. That'd be a huge win here, since it's the same image every time (and we'd only need to upload it once). It's unclear how well this correlates to real world usage of SVGs though. hixie-005.xml: hixie-006.xml: These are both the same as 4, except using a linear or radial gradient instead of an image. hixie-007.xml: Performance win for WR on this subtest.
The other alternative is just to use Direct2D for blob rasterization, as the extra speed would probably make these issues irrelevant. I think we want to avoid doing that if possible though.
tsvgx isn't something that we need to optimize for we can ship with this.
You need to log in before you can comment on or make changes to this bug.