Fix(clip): delete clipping region with restore #73
Conversation
Previously, the restore() method would update its pointer to the previous clipping region (stackIndex = n-1) in the stack without deleting the current clipping region (stackIndex = n). This caused problems for future save() calls, which would push a new clipping region onto the stack at location n+1 while only incrementing stackIndex to n, thus referencing the wrong region. This commit fixes the issue by deleting the current clipping region when restore() is called. By doing this, we lose the ability to inspect old clipping regions, but this is easy to change in the future if it is desired.
|
Added some tests to address incorrect behaviour from #58. I hope it's sufficient. |
| @@ -1477,6 +1477,7 @@ export default class CanvasRenderingContext2D { | |||
| if (this._stackIndex <= 0) return; | |||
|
|
|||
| this._transformStack.pop(); | |||
| this._clipStack.pop(); | |||
There was a problem hiding this comment.
Cant believe I missed this. Thanks for the pull request!
| @@ -51,4 +51,26 @@ describe('__getClippingRegion', () => { | |||
| ctx.restore(); | |||
| expect(region).toStrictEqual(ctx.__getClippingRegion()); | |||
| }); | |||
|
|
|||
| it('should restore the clipping region correctly when restored', () => { | |||
There was a problem hiding this comment.
We can consolidate these two tests into a single one, because we already test to see if the clipping region is properly set without restoring, right?
ctx.arc(1, 2, 3, 4, 5);
ctx.clip(); // push the arc to the clipping stack
ctx.save(); // push the current clipping region to the top of the stack
ctx.rect(1, 2, 3, 4);
ctx.arc(1, 2, 3, 4, 5);
ctx.clip(); // adds the path to the current stack clipping region
ctx.restore(); // restores back to a single arcIt would be best to utilize the afterEach() snapshots to validate context output in this case too, because it's already baked into each test. No need to add additional expectations.
There was a problem hiding this comment.
You're right. I just made the changes. Better?
| @@ -178,6 +178,7 @@ canvas.toDataURL.mockReturnValueOnce( | |||
| - [@hustcc](https://github.com/hustcc) | |||
| - [@jtenner](https://github.com/jtenner) | |||
| - [@evanoc0](https://github.com/evanoc0) | |||
| - [@lekha](https://github.com/lekha) | |||
There was a problem hiding this comment.
Thank you for your contribution!
There was a problem hiding this comment.
Thanks! It's my first one ever!
Tests have been combined and make better use of the afterEach snapshots.
| ctx.rect(1, 2, 3, 4); | ||
| ctx.arc(1, 2, 3, 4, 5); | ||
| ctx.clip(); | ||
| const region = ctx.__getClippingRegion(); |
There was a problem hiding this comment.
First, I want to admit that this test function does indeed assert that the restore() function works in relation to clip calls.
With that being said, I believe simplifying the tests here will go a long way in describing how the functions are supposed to work.
If possible, I would like to remove a few of the function calls in this test, so I will outline the reasons why I suggest them.
- On line 62, this code obtains the current clipping region, which normally would be able to be used, except that the
afterEach()callback already performs clipping region checks. Thus, we don't have to obtain the clipping region at all. - On line 64, this code calls
ctx.save()again, which becomes a confounding factor when proving that thectx.restore()function works. We should probably remove it to make things clearer. - Lastly, on line 65 creating another expectation here is not necessary, because we know the clipping region should only contain a single
Rectentry at this point. Again, this is handled by the snapshot expecation in theafterEach()callback.
All in all, great work. Please remove the lines in question, and I will accept the contribution.
Cheers.
There was a problem hiding this comment.
Thanks for working with me on this. I haven't been working with javascript long.
I tried removing lines 62 and 64-65, but then the test passes even when this._clipStack.pop() is not inside the restore() implementation, which doesn't seem right to me. I think the way to ensure that the clipping region has been popped off the stack is by calling ctx.save() -> ctx.restore() -> ctx.save() and confirming that the clipped region immediately after the two ctx.save() calls do not have the same identity.
The afterEach() snapshot check already occurs in a different test, which is what I thought you meant when you said to consolidate earlier.
Is there a better way to check that the pop happens?
There was a problem hiding this comment.
Okay. At the very least, we should make sure not use expect calls here. We can just inspect the state after the test runs, and that's enough.
As for your example, I think I'm being pedantic.
Just remove the expect calls from this test and we should be good.
There was a problem hiding this comment.
There's an additional test that doesn't require expect calls too. I can understand why they were added in the first place. They aren't necessary.
There was a problem hiding this comment.
That makes sense. Fixed.
|
@hustcc please release v2.2.1 with this pull request. Thank you. |
Previously, the restore() method would update its pointer to the previous clipping region (stackIndex = n-1) in the stack without deleting the current clipping region (stackIndex = n). This caused problems for future save() calls, which would push a new clipping region onto the stack at location n+1 while only incrementing stackIndex to n, thus referencing the wrong region.
This commit fixes the issue by deleting the current clipping region when restore() is called. By doing this, we lose the ability to inspect old clipping regions, but this is easy to change in the future if it is desired.