Opened 16 years ago
Closed 10 years ago
#2946 closed bug (fixed)
BGradient does not support alpha transparency
Reported by: | sdeken | Owned by: | stippi |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/Interface Kit | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
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.
Attachments (1)
Change History (8)
by , 16 years ago
Attachment: | twitchy.png added |
---|
comment:1 by , 15 years ago
Owner: | changed from | to
---|
comment:3 by , 10 years ago
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.
comment:4 by , 10 years ago
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.
Using ClipToPicture, I can make the rasterizing use unpacked scanlines, and this works fine. So I think the problem is that the packed scanline rasterizer doesn't handle changes in the alpha channel properly, and expect it to be constant for each span.
comment:5 by , 10 years ago
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.
comment:6 by , 10 years ago
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.
Incorrect gradient in radial alpha fill