Fri 28 Nov 2008 09:31:02 AM UTC, comment #13:
No discussion going on...
|
Thu 29 May 2008 03:20:58 PM UTC, comment #12:
I've already tested it, the bug is fixed. I'm just keeping this open in case Udo wants to discuss any different solutions he comes up with.
|
Wed 28 May 2008 02:54:53 PM UTC, comment #11:
Committed a simple patch. Please test.
Trying to optimize it, though.
|
Wed 28 May 2008 09:40:09 AM UTC, comment #10:
span_gradient_alpha only manipulates the alpha channel of the scanline (not R/G/B). probably it's used to set the transparency of a already present buffer.
|
Wed 28 May 2008 08:49:59 AM UTC, comment #9:
span_gradient_alpha, perhaps?
|
Wed 28 May 2008 08:38:30 AM UTC, comment #8:
Okay, I found a solution but I'm not happy with it since I think it is not optimal performance-wise.
It needs to premultipy() each pixel in the shape (like bitmap does). I think I'm missing some AGG way to get to the same result... :-/
Index: backend/render_handler_agg_style.h
===================================================================
RCS file: /sources/gnash/gnash/backend/render_handler_agg_style.h,v
retrieving revision 1.30
diff -r1.30 render_handler_agg_style.h
234c234
< m_gradient_lut.add_color(gr.m_ratio/255.0, agg::rgba8_pre(trans_color.m_r,
---
> m_gradient_lut.add_color(gr.m_ratio/255.0, agg::rgba8(trans_color.m_r,
251a252,255
> for (unsigned int i=0; i<len; i++) {
> span->premultiply();
> span++;
> }
(file #15756)
|
Tue 27 May 2008 09:59:40 PM UTC, comment #7:
The OpenGL renderer also has an extra alpha blending step to force premultiplication. When I remove this step, the OpenGL renderering is identical to the proprietary player. See attached.
So my guess is that premultiplication should not be done for gradient fills; only for bitmap fills.
(file #15753)
|
Tue 27 May 2008 09:53:30 PM UTC, comment #6:
I've enabled premultiplication and the result is identical to AGG (see screenshot). So I'm certain the problem lies in that area.
(file #15752)
|
Tue 27 May 2008 08:50:35 PM UTC, comment #5:
OpenGL does use Gnash's bitmaps to render gradient, and here's what it looks like (see attached):
(file #15751)
|
Tue 27 May 2008 11:40:06 AM UTC, comment #4:
Cairo doesn't use bitmaps for gradients (nor does it use sample_gradient()).
Omitting premultiplication from the gradient might give you a hint as to what's going on.
|
Tue 27 May 2008 10:00:07 AM UTC, comment #3:
Anyone familiar with Cairo can tell me if it uses Gnash' fill style bitmaps (fill styles converted to a 256x1 bitmap) or at least fill_style::sample_gradient() in some way?
sample_gradient() should produce the same output as AGG does, but perhaps Cairo has a different (correct) gradient function?
|
Tue 27 May 2008 09:52:35 AM UTC, comment #2:
AGG does a linear interpolation between the color stops. Flash however seems to play with hue/sat/lum or something (the green component has a higher GREEN component than both color stops).
|
Tue 27 May 2008 09:44:09 AM UTC, comment #1:
There is a green, but apparently AGG uses a different gradient function...
|
Mon 26 May 2008 07:44:33 PM UTC, original submission:
See the attachments of bug #20085. The pp rendering is shown in that bug. I'm attaching a screenshot of the current Agg rendering to this bug. Note that it does not have any green.
Cairo renders correctly.
|