Deferring PGraphics rendering?

chrisjj

Is there some way I can defer PGraphics rendering until after all my drawing calls are done?

E.g. queue the draw calls until endDraw()?

I am creating a PGraphics speculatively and when/if I find at the end of drawing that this image is not required, I would like not to have incurred the time cost of rendering.

jeremydouglass

Not sure. I'm not aware of a general purpose, push-button way of doing this, although there might be a way to achieve what you want depending on the details of your problem.

Which PGraphics renderer specifically -- Java2D, P2D, P3D? Are you trying to access the OpenGL graphics pipeline, or would you need this to work with any / all renderers?

What kind of information will let your program know if the image is required or not -- does it e.g. depend on checking the context of the PGraphics pixels array, is your decision independent of the output?

chrisjj

The renderer is the default one. No OpenGL. Decision is independent of the output.

jeremydouglass

Depending on your needs you might be able to create your own DrawQueue object that supports a limited number of commands -- although this could get extremely complex if you are trying to support the full API.

If it is independent of the contents then you might be able to simply draw after the check rather than enqueue.

I'm not really able to wrap my head around imagining what might engender this problem. It sounds like you might be describing wanting something like this?

beginDraw
drawCommand
if(check)
  bailOutWithoutRender
endDraw

If the decision is independent, why not simply make the decision, then conditionally call beginDraw and execute your draw code? Why create a PGraphics "speculatively" and then check?

if(check)
  beginDraw
  drawCommand
  endDraw

chrisjj

your own DrawQueue object

Seems like that would need storage and calls manually coded for each primitive.

If it is independent of the contents then you might be able to simply draw after the check rather than enqueue.

Each call is dependent of the contents - using local variables. In another language I'd use a closure, but ISTM Java's poor substitute for closures won't do here.

If the decision is independent, why not simply make the decision, then conditionally call beginDraw and execute your draw code? Why create a PGraphics "speculatively" and then check?

Parameters for the decision are not available until after parameters for the primitives are out of scope.

KevinWorkman

You're just going to have to use a boolean value to track whether the drawing should be done. Perform the checks, then check the boolean value and do all of the drawing if it's true.

chrisjj

The decision comes after, so that's not the thing I'd need to carry,

What I'd need to carry is all the data for the drawing - until after decision can be made.

That's my current implementation - and it's a PITA.

KevinWorkman

As always, it's hard to help you without seeing an example MCVE.

But I don't think there's a magical way to defer drawing, other than to use the approach that was outlined above.

Naively: why not just move the check to before the drawing?

chrisjj

why not just move the check to before the drawing?

The work that makes the drawings collects the data that (when drawing is complete) enables the check.

To move the check to before the drawing, I'd have to duplicate a lot of work.

Thanks for the suggestions. I'll take it the current PITA is the best solution in Processing/Java.

KevinWorkman

There's a concept in many drawing frameworks that says you should generally separate rendering code from your "business logic". Processing did away with that concept in favor of simplicity, but it sounds like you're at a point where it would come in handy again.

Many frameworks will have a separate step() function that does stuff like move characters around in an animation, do processing, read in data, whatever. Separately from that, they'll have a render() function that does the drawing but doesn't contain any logic.

So if you find yourself in a position where your business logic mixing with your drawing code is causing problems, you might want to take a step back and separate them.

chrisjj

Agreed. It's the age-old tradeoff between maintainability and performance. The separation would incur that work duplication.