I am using the default size command size(x, y) and noticed a severe penalty on interactive performance. As bit map size increased CPU utilization dramatically rises to the point that mouse inputs are undersampled.

The following images illustrate this, consecutively drawing a figure eight on simulated engineering paper:


20 dpi, 160 x 216 pixels:


40 dpi, 320 x 432 pixels:


60 dpi, 480 x 648 pixels:


It is not possible to draw on bitmaps larger than this interactively. The CPU just locks up.

This bug prevents the app from reaching the target image size of 992 x 1340.

When size(x, y, P3D) or size (x, y, OPENGL) is used interactive performance returns to normal FOR ALL SIZES, but with loss of background, to wit:

size(x, y, P3D) 160 x 216 pixels:


size(x, y, OPENGL) 160 x 216 pixels:


The .pde file to reproduce these examples is here.

Also, FYI size() will wipe out some object Processing data structures (like colors) it seems... try the following:

Code:

void setup()
{
  //HACK: Set the screen width and height(primitives)
  EDPaper eDPaper = new EDPaper(60); // units are dpi

  // Really, this should be first in setup()
  // Odd things happen when it's not.
  size(eDPaper.screen_Width, eDPaper.screenHeight, OPENGL);

  //HACK: So reinitialize our paper after setting the size
  eDPaper = new EDPaper(80); // units are dpi

  // um... everything else as usual
  eDPaper.drawPaper("Van Warren", "Processing Beta Test", "5/4/2004" );
}