Consistent movedX and movedY behaviour across zoom levels

[IIITM-Jay]

Resolves #7790

Approach Used:

• _updateMouseCoords() is called at the beginning of the existing function to store the previous frame’s positions.
• After computing the new mouseX, mouseY, the movedX and movedY values are derived in terms of deltaX and deltaY using pmouseX and pmouseY values and the current values of X and Y.

Alternative Approach:

Instead of calling _updateMouseCoords() at the beginning , we could use variables to store previous values which could then be used to find delta.

// Store previous mouseX and mouseY for calculating movedX/Y
    const prevMouseX = this.mouseX;
    const prevMouseY = this.mouseY;

// Calculate movedX/Y based on delta between current and previous positions
    const deltaX = mousePos.x - prevMouseX;
    const deltaY = mousePos.y - prevMouseY;

But, In my opinion there is no point in using extra variable to track the previous values. So, to avoid this manual tracking and leveraging the existing function, used the approach given earlier.

Observations:

Previously, the behaviour was:

Screencast.from.07-05-25.12.12.39.AM.IST.webm

Now, after fixing,

Screencast.from.07-05-25.12.08.48.AM.IST.webm

Browser Tested:

• Chrome

• Firefox

• npm run lint passes

[welcome]

🎉 Thanks for opening this pull request! Please check out our contributing guidelines if you haven't already. And be sure to add yourself to the list of contributors on the readme page!

[IIITM-Jay]

@SableRaf May I request you to have a look at this PR if this is what actually expected and the solution is aligned to the expected behaviour. Let me know if some changes are required, or needed some more modifications.

CC: @ksen0 , @limzykenneth , requesting some view points and feedback on the same.

[SableRaf]

Hi @IIITM-Jay, and thanks for taking the time to work on this!

Just to clarify: I opened #7790 to invite discussion and give maintainers a chance to confirm an approach before any work began. Following the contributor guidelines, we usually ask contributors to wait for the issue to be confirmed, an implementation is agreed on, and the issue is assigned before opening a PR.

In any case, I’m personally not the best person to review this PR, so I’ll leave space for others who are more familiar with this part of the project to chime in.

Thanks again for your interest and energy in contributing!

[IIITM-Jay]

Thanks @SableRaf for the response!

Yeah, I felt that this approach might be a bit more readable and maintainable, and it seemed to integrate well with the existing p5.js structure — especially since it avoids extra tracking variables by reusing _updateMouseCoords() which already handles previous mouse positions.

I thought it could be helpful to open a PR just to propose one of possible solution and make the discussion a bit more concrete. That said, yes, it's always a good practice to share multiple idea among maintainers and collaborators — I’ll share a few alternate approaches too in the issue so we can compare and decide on the most suitable one.

Hi @ksen0 and @limzykenneth , - Greatly Apologies for above, but as a part of contributing process, I have shared some of my thought process and ideas that I thought of in the issue itself. Would love to hear the feedback and more ideas/ discussion.

Thanks a lot again!

[IIITM-Jay]

Hi @ksen0 , @limzykenneth May I request for feedback and review on this PR to know whether I am on a right rack to solve this issue. I have discussed few points on the issue as well. Would love to incorporate the feedback changes too.
Thanks!

[ksen0]

Hi @IIITM-Jay thank you for your detailed work on this! A couple of things we saw in review:

• Because your proposed code is updating coords without checking for interaction flag, could you check if this regression has occurred? Because
• Right now the code logic seems to be: update pmouseX/Y (in the update coords call); then update mouseX/Y; then update pmouseX/Y a second time. So Could you confirm that pmouseX/Y are not getting overwritten here?

Because testing this involves interaction and time, it's not something that is covered well by 1.x unit tests. It would be really helpful if you include your manual tests (with visuals, preferably) in the PR, so that in the future it's more possible to manually spot regressions if they happen!

Please let me know if I can clarify anything.

[limzykenneth]

In addition to the inline comment, I find that there is another issue with Chrome, regardless of zoom issue which is when the example sketch used by @SableRaf in the original issue is view in Chrome, refreshing the page while not moving the mouse cursor then clicking on the page caused unintended movement on the circle in the middle.

2025-05-12.21-10-48.mp4

It may be unrelated to this issue though so we don't need to solve it in this PR. However both the above issue and the original issue for this PR does not present in 2.x from my testing, we are using pointerevents instead of mouseevents in 2.x so that may be the reason.

[IIITM-Jay]

Hi @limzykenneth and @ksen0 having explained my approach and giving explanations to each concerns after giving some time and observations to the issue, let me know your thoughts on the same. Regarding below, @ksen0

Ift would be really helpful if you include your manual tests (with visuals, preferably) in the PR

would you want me to write an example test under /test/manual-test-examples/mouse-events possibly with index.html and sketch.js

[ksen0]

Thanks so much for your thorough work here @IIITM-Jay !

would you want me to write an example test under /test/manual-test-examples/mouse-events possibly with index.html and sketch.js

I don't think that's strictly necessary, since this is in 1.x only. Because this PR is already very detailed, and can be found with git blame, it is enough. @limzykenneth do you think this needs formal manual test addition?

[limzykenneth]

@ksen0 @IIITM-Jay For now it's fine, the example in the original issue seems enough to test this case.

[IIITM-Jay]

Thanks a lot once again @limzykenneth and @ksen0 for giving time in reviewing it and giving feedback.

As per our detailed discussion as above, I have removed the the first calling of this._updateMouseCoords() as it does not add much to any noticeable change and other parts of the code already does the expected functionality. I have incorporated the feedback and requested a review again.

Let me know if something else needs to be done for this PR.

Thanks once again!

[limzykenneth]

Looks good. Thanks!