Closed
Bug 736460
Opened 12 years ago
Closed 12 years ago
When gfx.content.azure.enabled = true, -moz-radial-gradient seems to be broken
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla15
People
(Reporter: alice0775, Assigned: bas.schouten)
References
()
Details
Attachments
(2 files)
498 bytes,
text/html
|
Details | |
1.57 KB,
patch
|
jrmuizel
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•12 years ago
|
||
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
Assignee | ||
Comment 3•12 years ago
|
||
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
Assignee | ||
Comment 4•12 years ago
|
||
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.
Assignee | ||
Comment 5•12 years ago
|
||
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)
Comment 6•12 years ago
|
||
(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 7•12 years ago
|
||
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+
Assignee | ||
Comment 8•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/1a22fee1faad
Comment 9•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/1a22fee1faad
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.
Description
•