BGradient does not support alpha transparency

[sdeken]

To reproduce: Construct, for example, a radial gradient with two defined endpoints:

BPoint center(50, 50);
float radius = 50.0;
BGradientRadial g(center, radius);
g.AddColor((rgb_color){ 255, 255, 255, 255 }, 0.0);
g.AddColor((rgb_color){ 255, 255, 255, 0 }, 255.0);
SetDrawingMode(B_OP_ALPHA);
FillEllipse(center, radius, radius, g);    

Actual result: The ellipse is filled with a strange scanline-based alpha transparency which does not clearly correspond to the desired gradient. See attached image.

Expected result: The ellipse fades cleanly from solid white in the center to transparent on the edges.

[sdeken]

Incorrect gradient in radial alpha fill

[pulkomandy]

Test case added in hrev47556. The bug is still there...

[stippi]

I don't know what is going on. It doesn't look like the alpha channel is being written back to the scanlines. Or it is being ignored where the scanlines are rendered to the view (even though that is unlikely given that the drawing mode is set to B_OP_ALPHA).

I would start hunting down the bug by printf()'ing the contents of gradient scanlines to see what is going on.

[pulkomandy]

Ok, after some investigation, here is what I found:

• The gradient generator (agg_span_gradient.h) generates the right alpha and color values, so up to there things are ok.
• However, it generates a single span for each horizontal line. It seems something down the rendering pipeline doesn't expect the alpha value to change for pixels in a span, so the whole span is blended using the alpha value of the first pixel.

This can be shown using the gradients test:

• Scroll the view to the right
• Using the scrollbar arrow, scroll it back to the left one pixel at a time

The gradients drawing will be done one column at a time, and it will look good. If you scroll a bit faster (for example using the scrollbar knob), you can see the vertical bands using the same alpha value for each redraw rectangle.

I wanted to try using the unpacked scanline rasterizer using ClipToPicture but things went even worse. Will open a separate report for that.

[stippi]

B_OP_ALPHA can mean "use the constant alpha of the high color", or it can mean "use the alpha of the source pixel/color". Perhaps you have to set B_PIXEL_ALPHA as the alpha function as well? I think B_CONSTANT_ALPHA may be the default.

Also, try with B_OP_OVER once. For BBitmaps, B_OP_OVER works very similar and perhaps more intuitively than B_OP_ALPHA. I don't know whether the same span line blending function is resolved in the DrawingMode when drawing gradients and when drawing bitmaps, but I would expect it to be so. And I don't remember whether B_CONSTANT_ALPHA completely ignores the source pixel alpha for BBitmaps, or multiplies it, making B_CONSTANT_ALPHA (the alpha value of the current high color) work like a global alpha value which is multiplied with the pixel value of BBitmaps. IIRC, we have already established in another context that this would be nice but does not currently work that way.

[pulkomandy]

B_OP_OVER draws things fully opaque, except the edge of the gradient which has alpha = 0 and is not drawn at all. Things work as expected there.

I tried all 4 possible blending modes (just in case) and they all render exactly the same, as far as I can tell.

[pulkomandy]

Fixed in hrev47565.