Processing: 1.0.1
OS: MacOS X 10.5.5
Hardware: MacBook Pro
Java: java version "1.5.0_16"

Code: Source: http://www.somerandomdude.net/processing/helix/helix.pde
Ref: http://dev.processing.org/bugs/show_bug.cgi?id=1068

Description: the code referred above ran fine on Processing 0157, threw an
ArrayIndexOutOfBoundsException with Processing 1.0 and now throws an
OutOfMemoryError exception, seemingly as part of ellipseImpl.
On my machine, it runs for 4 frames (with 512 MB or 1024 MB settings in
Preferences) before throwing the exception on 1.0.1; it runs happily at
around 10 fps under Processing 0157 without crashing.
Given the fact that there isn't that much object creation within the draw()
procedure, i'd suspect the fix to ellipseImpl identified as part of the
resolution of bug #1068 may have some unexpected loose ends.
Note: i've attached a slightly revised code as the successive calls to
red(), green() and blue() to prepare for the fill() from the original call
can be optimized into a simple fill(pixelValue).


###
An OutOfMemoryError means that your code is either using up too much memory
because of a bug (e.g. creating an array that's too large, or unintentionally
loading thousands of images), or that your sketch may need more memory to run.
If your sketch uses a lot of memory (for instance if it loads a lot of data
files)
you can increase the memory available to your sketch using the Preferences
window.
Exception in thread "Animation Thread" java.lang.OutOfMemoryError: Java
heap space
at processing.core.PGraphics.vertexCheck(PGraphics.java:922)
at processing.core.PGraphics.vertex(PGraphics.java:965)
at processing.core.PGraphics3D.vertex(PGraphics3D.java:570)
at processing.core.PGraphics3D.ellipseImpl(PGraphics3D.java:2611)
at processing.core.PGraphics.ellipse(PGraphics.java:1517)
at processing.core.PApplet.ellipse(PApplet.java:6965)
at onori_helix.draw(onori_helix.java:78)
at processing.core.PApplet.handleDraw(PApplet.java:1406)
at processing.core.PApplet.run(PApplet.java:1311)
at java.lang.Thread.run(Thread.java:613)

edit]
code to reproduce the bug

I did a bit of investigation and the OutOfMemoryError seems to occur when
the accuracy variable goes very high, aka on my system, it fails upon
reaching the following state

[with a Capture in 640*480]
Accuracy: 6682024
sx1/sy1/sx2/sy2 1.9019634E7/9392934.0/-50980.79/-25407.69
x/y/w/h -5.0/95.0/10.0/10.0
PApplet.dist 2.1269544E7

[with a Capture in 64*48]
Accuracy: 2203046
sx1/sy1/sx2/sy2 2587.0574/1573.9927/5969624.5/3685300.0
x/y/w/h -21.5/9.5/1.0/1.0
PApplet.dist 7012515.5

oh bummer.. i know what the problem is, will just fix for the next release.
though i was hoping not to have to do one for a while. hrm.

though in the meantime, you have something strange in your code that's
causing ellipses to be 2 million pixels large, so you should look into what
might be causing that as well. my guess is that the 3D drawing is coming
too close to the z = 0 plane (see Help > Environment for info about the
coordinate system) or even that z is going positive (a no no) and causing
things to blow up.

(In reply to comment #4)
>
> though in the meantime, you have something strange in your code that's
> causing ellipses to be 2 million pixels large, so you should look into what
> might be causing that as well. my guess is that the 3D drawing is coming
> too close to the z = 0 plane (see Help > Environment for info about the
> coordinate system) or even that z is going positive (a no no) and causing
> things to blow up.
>

Thanks for looking into the matter.

From my further investigations, it looks to be coming from a combination of
translation and rotations on the X, Y and Z axis at different time in the
loop that creates the conditions for the ellipses center coordinates to
become big (the ellipses themselves are actually of 10x10 width x height,
aka width/columns and height/rows with width x height = 640 x 480 and
columns x rows = 64 x 48).

Interestingly enough, the unmodified code was running without issues in
0157. I haven't had the time yet to look at the differences between 0157
and 1.0.1 that would explain this (not that it really matters unless the
root cause for the difference is a nasty bug that creeped in somehow
somewhere).

right, i know it's a bug that arrived with the new ellipse implementation i
built pre-1.0 so will get it fixed up. was just saying how you can avoid it
in the meantime.

*** Bug 1093 has been marked as a duplicate of this bug. ***

# settings for the -XmsNNNm and -XmxNNNm command line option
run.options.memory = false
run.options.memory.initial = 128
run.options.memory.maximum = 512

# example of increasing the memory size for applets run externally
run.options = -Xms512m -Xmx1024m -ss 512k


(in preferences.txt, using this I was able to build applications that hold
huge amounts of data with recursive feature, consider this 'max memory mode')

Fixed for release 1.0.2.