SVG Dice demo shows low performance when drawing/intersecting gradients.

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
7 years ago
4 years ago

People

(Reporter: Steve Scott (pxbugz), Assigned: bas)

Tracking

(Blocks: 1 bug)

unspecified
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: ietestdrive, URL)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100805 Minefield/4.0b4pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4pre) Gecko/20100805 Minefield/4.0b4pre

The SVG dice http://ie.microsoft.com/testdrive/Performance/SVGDice/Default.xhtml looks to be as smooth as IE9 until the dice intersect with the gradient/graphics or each other.

The 'Vegas' theme has the worst performance, while 'low fidelity' maintains a fast framerate for the longest.

IE9 maintains high framerate throughout

Reproducible: Always

Steps to Reproduce:
1. Load SVG Dice and 'roll'
2. Change 'themes' and roll again to observe framerate differences.
Actual Results:  
Observe smooth animation of dice when they first appear.

When the dice cover gradient background or another dice framerate is drastically reduced.

Expected Results:  
Framerate should not drop dramatically over gradients and other dice

D2D on.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Blocking on the investigation; if this turns out to be unimportant, feel free to unblock.
Assignee: nobody → bas.schouten
blocking2.0: ? → betaN+

Comment 2

7 years ago
There are various SVG bugs with similar examples. The underlying issue is that when we move an object we invalidate where it once was. If two overlapping objects move we get two invalidates, 3=3 etc. The number of redraws grows rapidly with multiple overlapping objects. I think once we move to display lists for SVG (no bug for that yet) they can coalesce the invalidates.

Updated

7 years ago
Whiteboard: ietestdrive
(Assignee)

Comment 3

7 years ago
Robert, or JWatt, could you confirm here for me then that this is -not- related to graphics performance?
I can't confirm that. I profiled the testcase on Mac, in a debug build even, and we're spending almost all our time in nested calls to nsSVGUtils::PaintFrameWithEffects. A lot of computing mask alphas and suchlike. We're also spending TONS of time in io_alltraps, which indicates memory churn probably due to temporary surfaces. Maybe we can speed up graphics stuff, maybe we should be trying to cache the alpha surface for masks.

However, I do not recommend blocking FF4 on this.
blocking2.0: betaN+ → ?
The patches in bug 586954 might help here.
Depends on: 586954
blocking2.0: ? → -
Depends on: 610122
No longer depends on: 586954
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Blocks: 918620
You need to log in before you can comment on or make changes to this bug.