Closed Bug 667290 Opened 10 years ago Closed 1 month ago
Since Azure landed on Nightly - it fails some tests in the Asteroids benchmark
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110626 Firefox/7.0a1 Build Identifier: It fails one test completely and runs slower on another test Reproducible: Always Steps to Reproduce: http://www.kevs3d.co.uk/dev/asteroidsbench/ - this is Asteroids benchmark. Run it on yesterday's Nightly (without Azure), and today's Nightly (with Azure). Actual Results: Comparing today's and yesterday's Nightly builds: Test 2 is a bit laggy on today's build. Way slower then on yesterday's. Test 3 is painted absolutely incorrectly on todays build. It is fine on yesterday's build. Though Benchmark Score and Average FPS have increased each by 2 for me since yesterday's build. Expected Results: Test 3 is painted correctly. Test 2 runs a bit faster.
Test two is indeed slower with Azure. I cannot confirm incorrect painting in test 3 though. Test 5 seems to be missing the 'glow' I'm looking in to that. However could you describe the issues you're seeing with test 3, and perhaps add a screenshot?
Do we need separate bugs for the correctness and performance here?
The performance is probably a separate thing. For some reason non-azure also seems to be performing worse than expected here. FishBowl is very slow for me on the nightly, both with, and without Azure. I'm not sure what's going on here.
Forget what I said, I was running this in a profile with Direct2D disabled. So that caused the weird behavior. I can now reproduce the rendering bug.
The incorrectness only seems to occur on NVidia hardware.
The speed issue in test 2 is due to us needlessly drawing shadows (which needs some further optimization), because the shadow color is set even though using an opaque stroke. We should probably avoid drawing shadows when !shadowBlur, !shadowOffset and using an opaque pattern.
The incorrect rendering is caused by the downsampled render target not being cleared before we draw to it. NVidia appears to reuse this surface causing old content to linger in there and show up. We should clear it.
Assignee: nobody → bas.schouten
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #542036 - Flags: review?(jmuizelaar)
(In reply to comment #6) > The speed issue in test 2 is due to us needlessly drawing shadows (which > needs some further optimization), because the shadow color is set even > though using an opaque stroke. We should probably avoid drawing shadows when > !shadowBlur, !shadowOffset and using an opaque pattern. Yeah, that's a good idea.
Comment on attachment 542036 [details] [diff] [review] Clear downsampled target surface before using A comment about why we need to clear wouldn't hurt. A test case would also be nice :)
Attachment #542036 - Flags: review?(jmuizelaar) → review+
Fixed on mozilla-inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/a1a466be039e Leaving this open also pending a followup for a reftest that still needs some verification.
http://hg.mozilla.org/mozilla-central/rev/a1a466be039e Leaving open per comment 10, even if follow-up bugs are much welcome in these cases ;)
Target Milestone: --- → mozilla7
I just tested the asteroids benchmark with today's nightly(7.0a1 (2011-06-29)). With azure disabled tests 2,3 and 4 run faster than with azure on.
(In reply to comment #12) > I just tested the asteroids benchmark with today's nightly(7.0a1 > (2011-06-29)). With azure disabled tests 2,3 and 4 run faster than with > azure on. This is bug 667317. The cause is known for all three tests. 2 and 4 are fairly easy to fix, 3 is a little more complicated and is also a trade-off situation accelerated vs. non-accelerated shadows.
(In reply to comment #8) > (In reply to comment #6) > > The speed issue in test 2 is due to us needlessly drawing shadows (which > > needs some further optimization), because the shadow color is set even > > though using an opaque stroke. We should probably avoid drawing shadows when > > !shadowBlur, !shadowOffset and using an opaque pattern. > > Yeah, that's a good idea. So this is actually a problem.. On anti-aliased edges there will still be different rendering for with/without shadow rendering even if the shadowBlur & offset is 0, and the foreground color is opaque. I'm not sure what to do there.
This is not a problem. The "correct" rendering is that no shadow should be drawn since logically it's completely covered by the stroke or fill. The fact that we get AA artifacts in some cases if we draw the shadow and then the covering stroke/fill is a bug due to our use of coverage-based antialiasing. Avoiding that bug in some cases is a good thing, not a bad thing :-).
Is there anything left here that release drivers should care about tracking for Aurora ?
I don't think so; this bug is just open for a reftest, and presumably that patch will just ask for approval.
Oh, sorry for being away for long. Did any of your patches land on Nightly since I created this bug? Because now the situation is different for me, compared to the described in the initial post of this bug. Running the benchmark on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110728 Firefox/8.0a1 Tests 1, 2, 4, 5, 6 - are drawn correctly Test 3 - some asteroids have white shadow, the screenshot: http://img718.imageshack.us/img718/8721/watchthewhiteshadow.png Test 1 runs very fast, sometimes it slows a bit, but not for much and not for long. 100-111fps Test 2 runs pretty fast, sometimes it slows a bit, but not for much and not for long. 71-67fps Test 3 runs very slow. 8-9fps Test 4 runs very slow. Starts with 21-22fps, but then drops to the constant 14fps. Test 5 runs very very slow. Starts with 12fps, but then drops to the constant 5fps. Test 6 runs pretty fast. Starts with 111fps, but every time asteroids explode and numbers appear - it falls down to 37fps, after every explosion it gets restored to 71fps (not 111fps as at the beginning).
I can't reproduce this locally and the reporter's account is disabled. Is anyone else able to see this issue?
4 years ago
Priority: -- → P3
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.