Reduced test case. It can reproduce the issue for SPv1 with the explicit clip removed. It passes for SPv175.

Deleted: effect-clip.html 230 bytes

effect-clip.html 230 bytes View Download

Examined the operations we generated for SPv175 and found that MaskClip avoids the bug:
  clipRect 100,100 150x150 (for MaskClip clip)
  saveLayer 0,0 500x500 (for Mask effect)

For SPv1, we output the following operations:
  saveLayer 0,0 150x150
  clipRect 0,0 150x150

I'm wondering if  bug 750252  also applies to effects (e.g. opacity) other than masks. If not, I think we can just avoid the explicit clip for SPv175. Any idea?

Masks are special because it uses kDstIn blend mode. Every other blend mode are no-op when the source pixel is transparent, while kDstIn must clear the output when the source pixel is transparent.

Take your example, the mask must clear every pixels outside of the rect (100, 100, 50, 50). If we clipped the mask to its bounding box (in order to reduce rastered pixel counts), then (incorrectly) no pixel would be cleared. This is why in SPv175 we created MaskClip, so that both the mask target and the mask itself can be clipped to minimize rastered pixels.

The one-column-pixel artifact in  bug 750252  is probably related to AA clip. Which is likely solved with MaskClip too. In theory the MaskClip only applies to the output of the whole thing, while the mask itself should not be clipped while modifying its target (because both the mask and its target has the same clip node, there is no intermediate clip between them.), eliminating any possibility of pixels bleeding from the edges.

Cool. Thanks trchen@ for the analysis.