I know this is a specialized need, so it's not a priority request, but I'll ask anyway...

I would like to have the option of switching renderers during runtime. This is for a Java project where an application is set up to run as a PApplet inside a Frame. This then uses modules to draw different animated pieces. One might look best in P3D, another better in Java2D etc.

I've hacked up a switchRenderer() that basically does the relevant reflection calls that size() does and sets up a new renderer.

Code:

  public void switchRenderer(String renderer) {
    try {
	println("switchRenderer - "+renderer);
	Class rendererClass = Class.forName(renderer);
	Class constructorParams[]=
	  new Class[] {
	  Integer.TYPE,Integer.TYPE,PApplet.class};
	Constructor constructor=
	  rendererClass.getConstructor(constructorParams);
	Object constructorValues[]=
	  new Object[] {
	  new Integer(width), new Integer(height),
	  this};
	g = (PGraphics)constructor.newInstance(constructorValues);
	g.defaults();

    }
    catch(Exception e) {
	println(e.toString());
    }
  } 

Is there a nicer way of doing this? Will the renderers be more modular in the future, like BGraphics used to be? It was great to be able to set up multiple renderers that could be used separately.

size() is only allowed in setup(). My switchRenderer() does the normal renderer setup done by size(). My question is ultimately whether PGraphics could be disconnected from PApplet, so that one could instantiate several renderers. I realize there are issues with OPENGL etc.

The code you quote won't work. My code duplicates what size() actually does to initialize a renderer, but without the safeguards size() uses to prevent you from doing so outside of setup(). Duplicate image buffers is not a problem, in fact that's the whole idea. Your idea of passing null PApplets would probably work.

I guess I'm getting at a more general issue of how the processing.core classes interact. Right now the class hierarchy is obviously focused on working properly for users working within the Processing GUI. But for library writers or people coding in Java with Processing as a library, they might want to do things differently.

For instance, if one coukd abstract the renderers so that they are not tied explicitly to PApplet, one could use them a bit like BufferedImage. I'm aware that OpenGL probably won't work this way. There is also internal information (triangles, matrices etc) inside PGraphics which would be useful to expose to the user.

I'm of course aware that none of this is set in stone since we're still in BETA. I just wondered if anyone had tried doing this.

Thanks for the tips, Marcello. I have a working solution for now.