Wiebe,

A couple of notes:

> I'm putting together some simple Balloon3D examples and could 
> do with some advice on B3D's rendering engine.

Have a look at WonderlandCameraMorph and B3DSceneMorph to see what a common
setup of Balloon3D looks like. With the latest updates, the two mentioned
also show how to deal with accelerated rendering.

> This works fine for a short while until my VM crashes (at ~100MB). The
> problem is that 'flush' is calling:
> 
> B3DPrimitiveRasterizer>>mainLoop
> 
> which allocates memory every call (even when there is no texture):

Actually, this should not be a problem, since the dictionary should get GCed
when we're running out of memory. There must be some other strange thing
going on here.

> If I comment this out the image no longer grows but it still crashes
> randomly, usually (always?) at
> 
> B3DPrimitiveRasterizer>>mainLoop

This *sounds* as if it might be related to a bug that got fixed only
recently. Please make sure you have the latest VM and confirm that it still
crashes.

> This works great but it doesn't seem right that a new rendering engine
> should be created for every frame (a camera needs rendered to it, your
> matrix is lost, etc). Is there another way of doing this?

You should *never* rely on preserving state between rendering loops. This is
simply bad style and leads to many hard to find errors (just consider
conditional state changes and how they might or might not affect the next
frame). In general, you should call #reset if you recycle a renderer (this
will setup the renderer into the initial state) and then just pretend you're
dealing with the guy as if it were newly created. There is no speed penalty
whatsoever for this - the amount of time spent for setting up the initial
matrices and view transformations are exactly zero. They are not measurable
so there's just no point in attempting to recycle them.

> Is 'flush' the wrong call?

Flush will work here although you should generally call #finish if you want
to make sure that the rendering cycle is complete. The difference between
#flush and #finish is that 'flush' means "if there are any pending
primitives in the pipeline start rendering now" whereas 'finish' means
"flush and WAIT until the effects are visible on the output device". For
software renderers there's no difference between #flush and #finish (because
a software renderer will - after a flush - have completed the picture) but
for hardware renderers flush will only begin rendering (the graphics card
does this in parallel) - only after a finish you can be sure that the output
picture is really there. But be reminded that #finish can be expensive if
called multiple times in a rendering loop so call it exactly once if at all.

Cheers,
  - Andreas