Closed Bug 736460 Opened 13 years ago Closed 12 years ago

When gfx.content.azure.enabled = true, -moz-radial-gradient seems to be broken

Categories

(Core :: Graphics, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla15

People

(Reporter: alice0775, Assigned: bas.schouten)

References

()

Details

Attachments

(2 files)

Attached file sample html (deleted) —
Build Identifier: http://hg.mozilla.org/mozilla-central/rev/e5f6caa40409 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120316 Firefox/14.0a1 ID:20120316031151 When gfx.content.azure.enabled = true, -moz-radial-gradient seems to be broken Center color is not drawn because "stop" is not 0. Reproducible: Always Steps to Reproduce: 1. Start Firefox with Clean porofile + gfx.content.azure.enabled = true 2. Open http://ie.microsoft.com/testdrive/Graphics/Bayou/Default.html Actual Results: Center color is not drawn. Expected Results: Center color should be orange.
Graphics Adapter Description : ATI Radeon HD 4300/4500 Series Vendor ID : 0x1002 Device ID : 0x954f Adapter RAM : 512 Adapter Drivers : aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Driver Version : 8.950.0.0 Driver Date : 2-14-2012 Direct2D Enabled : true DirectWrite Enabled : true (6.1.7601.17776) ClearType Parameters : Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 200 WebGL Renderer : Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series) -- OpenGL ES 2.0 (ANGLE 1.0.0.963) GPU Accelerated Windows : 1/1 Direct3D 10 AzureBackend : direct2d
Blocks: 715768
I've determined this is caused by our custom radial gradient code which doesn't seem to be behaving exactly as expected here. I'll investigate further and fix this.
Assignee: nobody → bas.schouten
I've determined the underlying cause of the issue to be our gradient realization texture generation. If there is not difference in stops this will cause a division by zero and result in an empty pixel at that point. Here, this is the case for the first pixel in the texture, the color the center is clamped to, causing it to be empty. I will create a fix.
This fixes the issue, it's a little tricky what the -exact- behavior should be but I believe this is the best approximation. It fixes this issue, looks good and passes all canvas gradient tests.
Attachment #628909 - Flags: review?(jmuizelaar)
(In reply to Bas Schouten (:bas) from comment #5) > Created attachment 628909 [details] [diff] [review] > Deal with gradient stops in a single position > > This fixes the issue, it's a little tricky what the -exact- behavior should > be but I believe this is the best approximation. It fixes this issue, looks > good and passes all canvas gradient tests. Test case?
Comment on attachment 628909 [details] [diff] [review] Deal with gradient stops in a single position Review of attachment 628909 [details] [diff] [review]: ----------------------------------------------------------------- Mostly looks ok. A test case would be good though. ::: gfx/2d/DrawTargetD2D.cpp @@ +2145,5 @@ > + float interp = 0; > + > + if (nextColorPos != prevColorPos) { > + interp = (pos - prevColorPos) / (nextColorPos - prevColorPos); > + } I think this might be more clear as an if else
Attachment #628909 - Flags: review?(jmuizelaar) → review+
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: