P5.js: createGraphics sizing problem

Created on 2 Sep 2017 · 5Comments · Source: processing/p5.js

Nature of issue?

[x] Found a bug

Most appropriate sub-area of p5.js?

[x] Image

Which platform were you using when you encountered this?

[x] Desktop/Laptop

Details about the bug:

https://codepen.io/thinsoldier/pen/oemPqZ?editors=0010
In an image created by using a 100 wide createGraphics object, drawing a 50 wide rectangle within that creates a 100 wide rectangle instead of a 50 wide rectangle.

p5.js version https://cdnjs.cloudflare.com/ajax/libs/p5.js/0.5.14/p5.min.js

Source

thinsoldier

Most helpful comment

It would be a giant help if the documentation was simply updated to mention this quirk. If you're not already 100% certain that this behaviour needs to be changed then just accept that it's the way things are and will always be and mention it in the documentation.

thinsoldier on 5 Sep 2017

👍3

All 5 comments

Probably related to #2133. I would suggest visiting the forum for help at this point.

I'm thinking of trying to modify p5.Graphics so it can be a bit more intuitive even on high density display, what do you think @lmccart? Just this kind of problem keeps popping up.

limzykenneth on 5 Sep 2017

thinsoldier on 5 Sep 2017

👍3

I just encountered this as well and agree with @thinsoldier it would be really nice to have a note in the reference about this. It's easy enough to scale the createGraphics with window.devicePixelRatio, but baffling to newcomers who might not know about pixel density.

aferriss on 12 Oct 2017

Ran into this as well I have a simple fix as others said just check the devicePixelRatio in the call for rendering images with the image function otherwise having previously created a graphics object with create graphics it is using the scaled size.

if(devicePixelRatio!=1)
    this.drawingContext.drawImage(cnv, sx, sy, cnv.width, cnv.height, dx, dy, dWidth, dHeight);
else
    this.drawingContext.drawImage(cnv, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight);

Something like the above around line 48315 seems to resolve the issue for me and I don't think will affect displays without high dpi but not entirely clear to me if this is where the fix should be applied or if there's some underlying parts where it should be adjusted before getting to drawing the image.