Clipping region not functioning for block held in beaker

[chrisklus]

After #114 was implemented, a clipping region was in place to keep the back of the blocks opaque when they're in the beaker, regardless of wether they're resting or being held by a user. See behavior from dev.10:

At some point, this functionality stopped working when the block is being held inside the beaker. See the behavior on the published version:

@jbphet is going to look into this. Also assigning @ariel-phet for prioritization.

[ariel-phet]

Since this behavior was working before, and it is the desired behavior, marking as high priority since my guess is some investigation will yield a solution fairly quickly.

[jbphet]

This was due to a test that was using incorrect bounds for the beaker. I think this may be the result of an attempted optimization that I did that was done incorrectly. It should be fixed now, and we should have it verified in the next release. Unassigning until then.

[KatieWoe]

This can still happen a small amount if the two blocks are stacked on top of each other. The chunks in the water are lightly visible where the top of the bottom block and the bottom of the top block overlap.

[KatieWoe]

It is worse in the published version

[KatieWoe]

Also, not sure if this is intended, but the chunks of the bottom block are visible in this area, even without moving the top block.

[chrisklus]

From #212 (comment):

This can still happen a small amount if the two blocks are stacked on top of each other. The chunks in the water are lightly visible where the top of the bottom block and the bottom of the top block overlap.

Right! Good catch. If the upper block is being grabbed, there is no clipping mask wherever the blocks overlap, as if their two clipping masks are canceling each other out. @jbphet do you think this is reasonable to fix/worth fixing?

It is worse in the published version

This issue was found after publication, so the original (and much more noticeable) problem identified in #212 (comment) is present in the published version.

Also, not sure if this is intended, but the chunks of the bottom block are visible in this area, even without moving the top block.

Since both blocks are transparent, this is intentional.

[jbphet]

@jbphet do you think this is reasonable to fix/worth fixing?

I took a look at the code, which is in BeakerContainerView, and specifically in the addProjectedBlocksToClipArea method. Unfortunately, this would not be easy to correct. The clipping area that is created to hide the energy chunks is drawn with "holes" for the blocks, and if the holes overlap, the energy chunks behind them (i.e. in the water) can show through. There is specific code in place to handle that case where the blocks overlap due to be stacked, and in that case it just draws a single shape. In the case where the user is dragging a block and they overlap, we'd have to create a single shape the encompasses both, which would be tricky in situations where the top block is dragged such that it is not directly above the bottom block.

It might be possible to use some of the constructive area geometry (CAG) methods to make a union of these shapes. I'm skeptical that this would work, however, since the winding direction of the holes in the clipping mask have to be drawn in the opposite direction of the outside of the mask, and the CAG methods don't appear to provide any control over this.

So, bottom line, I don't think it's worth the time and effort to try to address this. If it's any consolation, even with this (IMO minor) issue, the clipping still works way better than it did in the Java version.

Since the more significant problem that originally motivated this GitHub issue is fixed and verified, I'm going to close this issue.