fix(image): account for destination pixel density in p5.Image copy and blend

[Pcmhacker-piro]

Resolves #9169

Overview

Fixes a high-DPI scaling bug where calling copy() and blend() on a p5.Image with pixelDensity > 1 (e.g. on Retina or high-DPI displays) failed to scale the destination coordinates (dx, dy, dw, dh) to the physical dimensions of the backing canvas.

Cause of the Bug

In p5.Image.prototype._copyHelper:

• Source coordinates were scaled by s = srcImage.canvas.width / srcImage.width.
• However, dstImage.drawingContext is a 2D canvas context without an automatic DPI scale transform.
• drawImage() was called with unscaled logical destination coordinates dx, dy, dw, dh.
• On a high-DPI target (e.g. pixelDensity = 2), the copied image covered only 1/4th of the intended destination area in the top-left corner, leaving the rest untouched.
• Because p5.Image.prototype.blend() internally delegates to copy(), it was similarly affected.

Changes:

• In src/image/p5.Image.js, computed destination pixel density scale factor const d = dstImage.canvas.width / dstImage.width.
• Passed d * dx, d * dy, d * dw, d * dh into dstImage.drawingContext.drawImage().
• Added unit tests in test/unit/image/p5.Image.js for p5.Image.prototype.copy and p5.Image.prototype.blend verifying correct high-DPI destination rendering.

PR Checklist

• npm run lint passes
• [Inline reference] is included / updated (N/A)
• [Unit tests] are included / updated

[Pcmhacker-piro]

Hi @ksen0, could you please take a look at this PR when you have a moment? It fixes a high-DPI scaling issue where p5.Image.prototype.copy and blend did not scale destination coordinates by pixelDensity, causing copied content to be truncated to 1/4th of the intended area on Retina displays. Unit tests and linter are both passing. Thank you!

[p5-bot]

Continuous Release

CDN link

• https://raw.esm.sh/pr/p5@0e7e74a/lib/p5.min.js

Published Packages

• https://pkg.pr.new/p5@0e7e74a

Commit hash: 0e7e74a

Previous deployments

9d2ffa0

• https://raw.esm.sh/pr/p5@9d2ffa0/lib/p5.min.js
• https://pkg.pr.new/p5@9d2ffa0

---

This is an automated message.

[perminder-17]

I suspect this change might also affect mask(). It already passes imgScaleFactor * this.width and imgScaleFactor * this.height to copy(). Since _copyHelper() now scales the destination dimensions again, could this cause double scaling when the image’s pixel density is greater than 1?

[Pcmhacker-piro]

Great catch @perminder-17! You were right — mask() was pre-multiplying the destination coordinates by imgScaleFactor (lines 1013–1014), and since _copyHelper() now also scales by the destination pixel density, this caused double-scaling when pixelDensity > 1.

Fix: Updated mask() to pass logical (unscaled) this.width / this.height as destination dimensions, letting _copyHelper() handle the pixel density scaling internally.

Added: A unit test for mask() at pixelDensity(2) that verifies no double-scaling occurs.

All tests pass (8 passed, 7 todo). Lint is clean (0 errors).