Fri 10 Jul 2009 05:34:57 AM UTC, comment #12:
Surprisingly enough the reason for the graphical artifacts was the smoothing. Now Gnash doesn't do it by default, they are gone, and only appear in "best" quality. The pp only allows up to high quality in this SWF. I'd consider this fixed.
|
Tue 16 Dec 2008 10:38:23 AM UTC, comment #11:
This isn't fixed. It's still just that one instance. Image characters loaded from JPEG or from DefineBitsLossless(2) are expected to be premultiplied with alpha. Now they are, which fixed various JPEG problems. It would be useful to know what that character is.
Agg premultiplies again after applying a cxform (seems correct), so the different cases are:
DefineBitsLossless tag: we leave the data alone as it's supposed to be premultiplied. There are three different formats for alpha, so lots of room for error here.
DefineJpeg tag: we adjust RGB using std::min with alpha.
Any bitmap character with cxform: agg applies and premultiplies.
|
Sun 02 Dec 2007 07:34:21 PM UTC, comment #10:
The last instance I've tested to be a result of premultiplication when it is not needed. I haven't figured out what the criterium for a bitmap is for wanting premultiplication, though.
|
Wed 07 Nov 2007 02:32:46 PM UTC, comment #9:
Could it be that this rose has _alpha < 100 ?
See my previous post - that might be the problem...
|
Sun 28 Oct 2007 11:26:55 AM UTC, comment #8:
There is one instance in the original movie (roses.swf) that still has those artifacts. All the other ones have been fixed. It's quite late on in the movie at the bottom right.
I've attached a screenshot generated from the latest cvs build, although that clearly doesn't explain why this case is different from the fixed ones.
(file #14233)
|
Wed 24 Oct 2007 06:26:45 PM UTC, comment #7:
I confirm your patch fixes the problem. I attached a new test case that shows that when premultiply()ing the colors get wrong.
I'll check in a better patch soon.
However, to be honest, this makes absolutely no sense to me.
Have a look at generate_span() in render_handler_agg_style.h.
The patch prevents premultiply() when no color transform is requested. However, the premultiply() is necessary when there is a cxform. This is just a optimization, the
if (!m_cx.is_identity())
branch could as well be done always. In case of a identity cxform the transform() method would do nothing which means all pixels are just premultiplied, ie. would be the same as the "else" branch.
However, commenting out line 157 (span->premultiply();) leads to wrong results (try attachment).
Strange...
(file #14197)
|
Wed 24 Oct 2007 06:04:08 PM UTC, comment #6:
Can you please test your patch with alphatest2.swf ?
(file #14195)
|
Wed 24 Oct 2007 05:55:26 PM UTC, comment #5:
I don't think it's AGGs fault since also OpenGL suffers from it.
Attached new testcase that works well with current CVS HEAD.
(file #14194)
|
Wed 24 Oct 2007 05:21:15 PM UTC, comment #4:
Here's a patch that fixes the bug in Agg. It removes the second premultiplication step from the bitmap style handler. Since I don't understand why this was necessary in the first place, I suggest this patch is tested thoroughly before being applied...
(file #14193)
|
Wed 24 Oct 2007 07:33:04 AM UTC, comment #3:
The same problem has probably been reported in bug #21409 (i.e. we have an additional testcase).
|
Tue 18 Sep 2007 04:35:48 PM UTC, comment #2:
Not really. This is not AGG related; OpenGL shows the same image.
Perhaps these are PNG images (just guessing) and the alpha channel is not decoded / processed correctly?
Attached screenshows of Gnash (AGG & OGL) and Adobe Flash rendering.
(file #13980, file #13981, file #13982)
|
Tue 04 Sep 2007 06:32:10 PM UTC, comment #1:
A job for Udo, looks like..
|
Tue 04 Sep 2007 03:42:31 PM UTC, original submission:
This SWF6 movie seems (I admittedly haven't looked at it on the proprietary player) to have a masking problem or something similar. The roses have a grey halo artifact most of the time. Occasionally it flickers away.
(3.5 megabytes)
http://www.backingblair.co.uk/roses/roses.swf
The loading status doesn't display either.
Otherwise it works flawlessly, which is excellent!
|