See http://dev.processing.org/bugs/show_bug.cgi?id=123 - strokeWeight() doesn't do anything in P3D right now (unclear whether it will in the future, either - a 3d stroke is a strange and somewhat undefined thing, some 3d graphics cards don't even handle this completely consistently).  My suggestion would be to create a function that actually draws geometrical strokes (with thickness) if you need them to transform properly in 3d; for 2d, you might look up fat line rasterization methods and do things pixel by pixel (I assume strokeWeight will work in P2D once that's back, so some of the relevant algorithms might already be in PGraphics2d.java or PPolygon.java in the source for Processing if you dare to poke around).

Hmm, I don't think a camera() call clears the canvas by itself - are you sure you're not calling background() somewhere?  If you mean, rather, that the geometry is not stored between frame draws, that is correct - if you move the camera and want geometry to appear in the new position relative to the camera, you have to explicitly redraw it.  camera() and all the other transformation functions basically just set up a framework that decides where to draw a triangle on the screen when you call a triangle drawing function.  You still have to call that drawing function every time you want the triangle to appear.  Put another way, the only remnant of a drawing call that you've made after it returns is the set of pixels that it changed on the screen (or in the pixels[] array).

For a side scroller, you actually need to change all the pixels on the screen every time the camera moves, so you'll at least have to redraw everything that is visible.  A fairly fast way to do this is to chunk up your levels along the x axis in blocks the size of the screen width, and then draw the geometry in (and only in) the two chunks that should be visible wrt the current camera positioning.  That way if have a ridiculous level with 20,000 objects that extends to a thousand times the screen width you never have to draw more than about 40 objects at once, which should not be too much strain on a processor.  You could also sort all your geometry along the x axis and just pick out what you need to draw from the sorted list.  Either way is a bit of bookkeeping for a lot of performance gain.

That said, if you would prefer to preserve _exactly_ what was drawn, and there's no nice/efficient way of redrawing it, you could always shift it over by a pixel (sort of - I'll explain) using the following draw loop (only works fast and correctly in P3D, though), obviously with your own drawRightEdgePixels(int) function that does exactly what it says (the int is a marker to tell it where the camera is):

Code:

int position = 0; //position of camera along x axis
void draw(){
  loadPixels();
  for (int i=0; i<pixelShiftPerFrame; i++){
    System.arraycopy(pixels, 1, pixels, 0, pixels.length-1);
    drawRightEdgePixels(position++);
    //Note: w/o this function actually drawing
    //the right edge pixels, pixels will wrap
    //around from the left edge shifted up by
    //one pixel.
  }
  updatePixels();
}
 

Honestly, though, unless your drawing functions are so detailed that you alter every pixel individually as they enter the screen, this is going to likely be slower than simply redrawing all the visible geometry, and the bookkeeping becomes enormously difficult.  OpenGL has very little overhead for drawing sprites, so I think a platformer is probably best done with a redraw every frame.