[gs-bugs] [Bug 692593] memory overflow(s) in shape related code

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Sun Oct 23 09:48:43 UTC 2011


--- Comment #1 from zeniko at gmail.com 2011-10-23 09:48:42 UTC ---
FYI: We've used a different approach for implementing blending in our GDI+ draw
device, using backdrop flattening instead of shapes. The base idea is (cf.

For each fz_begin_group we create an empty layer into which subsequent draw
operations paint (pushClipBlend, which uses recordClipMask -> pushClipMask for
actually creating the layer).

All other operations that push a layer to the stack also start with a new empty
layer (fz_clip_image_mask and fz_begin_mask) as would the remaining clipping
operations (however clipping is handled by GDI+ for us).

For fz_end_group we walk up the stack until the first isolated group and then
first flatten the backdrop from there (popClip -> _applyBlend ->
_flattenBlendBackdrop). For the flattening, we either start with an empty
backdrop , if that bottom layer is knockout, or with a copy of that layer if
it's non-knockout. Then we recursively blend in all non-knockout layers.
Finally, the current group is blended into the so computed backdrop (which will
be fully opaque for non-knockout groups) and the result copied over the group's
parent layer.

Any other call to fz_pop_clip also just copies the current layer over the next
lower layer on the stack (after applying a mask, if there is one) (popClip and
optionally _applyMask).

This approach seems to yield the expected rendering for all the documents in my
test collection. Do you see any reason why it shouldn't? And if not, any reason
not to proceed like this for draw_device.c instead of the shape approach?

Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the gs-bugs mailing list