Closed Bug 611975 Opened 10 years ago Closed 10 years ago

Gradients on stroke broken

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b8
Tracking Status
blocking2.0 --- final+

People

(Reporter: marek.raida, Assigned: longsonr)

References

()

Details

(Keywords: regression, testcase)

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101112 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101112 Firefox/4.0b8pre

My old demos are working well up until FFX4 Beta 6, but latest builds are broken, compare rendering... 

Reproducible: Always

Steps to Reproduce:
1. Open file from URL or from attachment
2 [review]. Compare rendering of stroke of top front text
Actual Results:  
Stroke is too bright, almost white...

Expected Results:  
Stroke should be darker, visible...
Attached image Simplified testcase
Could you narrow down the range when things changed to a single day using http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ please?

You would be looking for mozilla-central builds.
Yes, sure. There is result of my investigation

Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101030 Firefox/4.0b8pre  OK
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101104 Firefox/4.0b8pre  OK
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101105 Firefox/4.0b8pre  OK
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101106 Firefox/4.0b8pre  KO
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101107 Firefox/4.0b8pre  KO
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101119 Firefox/4.0b8pre  KO

and result is that problem is in some patch to version 2010-11-06. Hope this will help.
Marek
That produces this range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5947e95a21d1&tochange=2b612890113b
...which includes:
  http://hg.mozilla.org/mozilla-central/rev/2e2ab9de2222
  Bug 484953 - speed up display of text that is both stroked and filled

Looks like a strong candidate.
Blocks: 484953
Keywords: regression, testcase
Version: unspecified → Trunk
I can confirm this bug (on Linux), comparing my nightly vs. Firefox 3.6
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101121 Firefox/4.0b8pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Summary: Gradients on stroke broken (probably after change of HW acceleration turned on) → Gradients on stroke broken
Perhaps that setMatrix getMatrix foo was needed after all...
Assignee: nobody → longsonr
blocking2.0: --- → ?
Attached patch patch with reftest (obsolete) — Splinter Review
This just reverts the removal of the set/getMatrix lines from bug 484953. Included is a reftest so we don't remove these lines again.
Attachment #492456 - Flags: review?(roc)
Attachment #492456 - Attachment is obsolete: true
Keywords: checkin-needed
Whiteboard: [needs landing]
The reftest might need disabling on a mac if it fails due to bug 568881
http://hg.mozilla.org/mozilla-central/rev/86c3a0e9fa87
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla2.0b8
This turned the Windows optimized reftests orange.  I backed the patch out.  Bug 614324 has been filed for the oranges.

http://hg.mozilla.org/mozilla-central/rev/c639bd049de8
Status: RESOLVED → REOPENED
Depends on: 614324
Resolution: FIXED → ---
The reftests look like they would if the patch never landed. I'll try a try server build but at the moment it doesn't make much sense to me what's happened.
I just built an optimized Windows build and ran it and the reftest passes. I might try landing this with the reftests random_if on windows and then enable them on windows a day or two later to ensure we've had complete rebuilds there.
relanded with windows marked as random_if. http://hg.mozilla.org/mozilla-central/rev/e2bc7992d304
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Does not appear to have been fixed.


Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101127 Firefox/4.0b8pre - Build ID: 20101127012819
Try tomorrow. I don't think that one has the fix in it.
(In reply to comment #16)
> Try tomorrow. I don't think that one has the fix in it.

It's tomorrow and the problem is still there.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101128 Firefox/4.0b8pre - Build ID: 20101128132459
Not for me it isn't. I've even downloaded a nightly to test it, but not a 64 bit one. Please raise a new bug to describe what's still wrong.
I can confirm that enclosed testcase / original animated demo / is working for me again (in latest build) ;-)
Thanks Marek.
I wonder if Gary is hitting whatever windows issue that the Windows Opt test boxes were running into...?
I downloaded a nightly and checked the reftest. It looks the same to the naked eye.
But as you said in Comment 12, the reftest looked quite different on the windows opt test box -- on that machine, it looked as if the patch never landed.  I'm proposing that Gary's configuration matches that test machine in some way such that he's hitting the same issue.

In any case, whatever that issue ends up being, we should figure it out in a new bug, as you said in comment 18.  Gary: if you could, please file that bug, assuming that you can reliably reproduce the issue in the most recent nightly. :)
Well, I checked it once again and this time on Windows7 with D2D acceleration layer and it is still broken => but on other box Windows XP it is fixed already, as I wrote previously, so the difference can be OS and type of HW acceleration?
Select: Options > Advanced > General > "Use hardware acceleration when
available"

And uncheck the box to disable. If that fixes it you should probably raise a core->graphics bug to track it.
You're right, with D2D disabled it works correctly.
I'll submit another D2D related bug soon...
You need to log in before you can comment on or make changes to this bug.