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

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Alice0775 White]

Attachment: sample html

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.

Comment 1

[Alice0775 White]

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

Comment 3

[Bas Schouten (:bas.schouten)]

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.

Comment 4

[Bas Schouten (: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.

Comment 5

[Bas Schouten (:bas.schouten)]

Attachment: 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.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

(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

[Jeff Muizelaar [:jrmuizel]]

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

Comment 8

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1a22fee1faad

Comment 9

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/1a22fee1faad