Methods bound to p5 "canvas" vs. offscreen p5 "graphics"

Hi folks,

I’m finding that some everyday p5.js methods are not bound to a p5 canvas in the way that I expected. But they are all bound ok to a p5.Graphics created with createGraphics().

So, if I create a canvas, with

  let canvas1 = createCanvas(500,500, P2D);

I expected that the following lines would work equivalently …

  let tgt = canvas1;

but in fact only the first bare “colorMode()” works, the next two fail with …

  Uncaught TypeError: canvas.colorMode is not a function

Here’s a sketch showing the problem.

You can comment/uncomment the calls annotated ??? to see the issue.

The context is, I want to render a version of a scene on-screen, in a canvas say 1200 x 900, and render a much higher-resolution in an offscreen p5.Graphics buffer, say 12000 x 9000, and then save the high-def buffer to a file with saveCanvas(). The offscreen rendering and saving all works fine, but it would be convenient to use the same rendering sequence and just change the render “target”, as shown, ie .

  tgt = canvas;

  tgt = buffer;

My impression is that this is an intended functionality of p5.js, it seems to be shown at points in the examples and tutorials, but its implementation seems to be inconsistent.

I could be very wrong here, my JavaScript is not quite good enough to decode the prototype trees and object properties etc. etc. to see what canvas.colorMode() and the others think they’re doing.

Thanks for any comments.
Regards, Greg E.

please link to any example showing

< object >.colorMode(...);

i think the idea is to set the way the interpreter understands following color ranges,
also reference states

Note: existing color objects remember the mode that they were created in

for only.

but i think you can not read or write that from or to objects.

TypeError: canvas1.colorMode is not a function (sketch: line __)

( possibly you make that a feature request? at
but not fully understand its use )

Hi kll, thanks for the reply.

I don’t have an actual reference to a use of <object>.colorMode(...). I was kind of generalising that many methods seem to be callable as context.method(...), where context is either the physical canvas, or a object. But yes … it could be that the color mode is a system-wide piece of state. Or at least system-wide within a p5 instance. It wouldn’t be a problem to my code if that was true.

My next step should be I guess to trawl all the p5.js tutorials and examples a bit more, happy to do that.

Cheers, GE.

1 Like

wondering if you found a solution here? i’m also seeing this inconsistency which gets more complex when you have are layering multiple buffers with different blend modes…

Hi @DCsan … from memory I didn’t get a good response here or on the p5.js GitHub discussions (well, I think I raised it on GitHub, I’ll have to check)… I just carried on coding it clunkily - using someP5Call() on the default canvas, and myGraphic.someP5Call() in an offscreen canvas. I didn’t do the research through all the examples that I said I would, I was able to continue well enough. I’d be interested in your experiences. Cheers.

FYI createCanvas() returns a p5.Renderer object:

While createGraphics() returns a p5.Graphics object:

I’ve already ranted many times in this forum about the fact a p5.Graphics object is a hack which merges p5.Renderer & p5 types together.

We can access all p5 properties over a p5.Graphics object; even something like random(), cos(), createGraphics(), etc.

1 Like