davepagurek
commented
1 month ago Previously, get() would always return an image of pixel density 1, regardless of the density of the main canvas, making it impossible to capture the full resolution of the canvas to a p5.Image. Now, it continues to use the same density as the main canvas. So while previously get() would return an image 1/100th of the size of the main canvas if you used pixelDensity(10), it will now be using the full size.
I think if you wanted to replicate the old behaviour, you would have to createGraphics(width, height), set its pixel density to 1, and then use image() to draw the main canvas to the graphic (which is essentially what it was doing under the hood before.) I tried making a little demo here: https://editor.p5js.org/davepagurek/sketches/qA0891h1z
Also, in that version, you can try setting the pixel density of the graphic to 10 too, and it doesn't lag nearly as much as the image version. Seems to be garbage collection is the main thing making it lag, so if you reuse a graphic rather than making new images, it seems to run more smoothly.
Topic
This is pretty odd issue – but ever since p5.js version 1.8.0 was released, nearly all of my previous sketches which experiment with visual feedback, using
get()(especially when combined withpixelDesnity()for upscaling images) – slowed to a halt (even on an M1 Max). I know some significant changes happened to both of these functions in that release, and that there were some sizing issue that got cleared up, however is there a chance an accidental bug still exists in the updates that is causing this?Example: https://editor.p5js.org/ffd8/sketches/r367LzyK7
prod = 10– which lags out on my M1 Max, however with v1.7.2 (or any version prior) it works just fine.Sure, this is using
pixelDensity()in a weird way – but these sketches worked fine on a mobile phone with normalpixelDensity(), however if I try updating to later versions, they also lag out... so I believe the issue is withget().