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.

@ksen0 @limzykenneth - 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!