As of the latest isolated/knockout changes, some blendmodes seem to use the wrong background. See e.g. the document l16.pdf from http://code.google.com/p/sumatrapdf/issues/detail?id=51#c18 where in the top half all circles render intransparent instead of semi-transparent.
Fixed in commit: commit 332b2aed1f1f17bdcafdffe2b9f773e00d7e6a0d Author: Robin Watts <Robin.Watts@artifex.com> Date: Mon Aug 1 22:01:46 2011 +0100 Fix bug 692377: Incorrect rendering of blending groups. A combination of constant alpha and non-zero blending modes resulted in incorrect rendering. Various fixes seem to have made it work: * Allow for non-full alpha when blending non-isolated groups back. * Clamp blended pixels to allow for overflow. * Allow for alpha in the shape blending.
Thanks. However the regression hasn't been fixed completely, yet: Please compare in the linked document the left half of the red circle of the right graphic on the second line with all the other red circles (it should not be lighter than any of the other such circles).
Another document that's significantly regressed is the PDF from bug 692203. BTW: Would it help you if we shared our document collection we use for regression testing?
zeniko: Yes please. We have both a HUGE repo of files that's too large to run on every commit, plus a small set that doesn't cover everything. I'd be interested to see what set you have. Thanks.
Fixed (I hope) in: http://git.ghostscript.com/?p=mupdf.git;a=commit;h=4ffa961d35b8985fd041f27737d06d9c59e41d6b Author: Robin Watts <Robin.Watts@artifex.com> Date: Thu Aug 4 14:21:11 2011 +0100 More changes to blending of groups. In an effort to solve bug 692377, examine what ghostscript does, and move mupdf into line with it. Firstly, it seems that rather than collecting a pure 'shape' plane ghostscript keeps a 'shape-with-alpha' plane. Only a tiny change is required to move mupdf to the do the same thing, so done here. Secondly, it seems that ghostscript 'uncomposites' the result of non-isolated groups, before applying the blend mode. It's not clear to me that this is entirely correct; this 'uncomposite' operation assumes that all compositing has been done internally with the 'normal' blend mode. Nonetheless, I do the same here, and it seems to work. This 'uncomposite' operation may yet turn out to be a source of bugs if I have muddled the use of premultiplied and non-premultiplied components, but it seems to work on the testfiles I have.
FYI: The file linked from comment #0 still renders wrong: now most of the circles in the top half are too dark. This issue still isn't properly fixed, I'm afraid.
Created attachment 7759 [details] reference screenshot (Adobe Reader)
Created attachment 7760 [details] screenshot (MuPDF up to 4ffa961) Please compare this screenshot against attachment #7759 [details].
BTW: Other visible regressions are the files from issue 1001, 1190, 1286 and 1520 in the collection I've sent you (mostly unexpected gray borders, in two cases unexpected gray backgrounds).
Another visible regression: page 7 of http://research.microsoft.com/en-us/um/people/kopf/pixelart/paper/pixel.pdf
The latest changes solve the l16.pdf problems, but others listed in this bug still remain. This note is just to confirm that I understand the problem is not completely solved.
With this commit: commit f76fe4d82dbde6c3d9f90839c03af1afdc5ae964 Author: Robin Watts <robin.watts@artifex.com> Date: Fri Dec 30 16:29:03 2011 +0000 Fix typo in draw/draw_affine.c causing offsetting of shape plane The shape plane was being incorrectly offset from the dest plane. This could have caused SEGVs or incorrect results when blending back. This solves the hivemind.pdf iphone being clipped on the right hand side. All the problems here seem to be fixed. Please let me know if you spot any cases I've missed. Thanks.