In the P3D textured triangle code, the bilinear interpolation of the
texture is sometimes reading off of the end of the texture array if the
texture is scaled to the size of the polygon. The exceptions generated are
being caught, but at a significant performance penalty - in some cases a
hundred or more are thrown/caught per frame, and while it costs very little
to wrap something in a try/catch, it costs a lot to actually throw and
catch an exception.

Don't have a cut-n-paste test case at the moment, since to see the
exceptions being thrown requires a recompile of the core. You can see the
difference if you texture a square, watch the frame rate, and change your
view so that the bottom of the image is/isn't visible - on my computer,
making the bottom edge visible makes my frame rate drop from (in the
particular instance I'm looking at) 14.5 to 12, all else being equal.

Need to add some sort of bounds checking as we interpolate - I'm going to
try to handle this along with bug 103 (texture warping in P3D), since I'm
already messing around with those sections of code for that one.

Just a note on this one - with the edits for bug 103 I did add in a partial
bounds check, though things are still not absolutely perfect. What was
happening before was that the entire bottom row of pixels in a texture were
causing exceptions whenever read (which are all caught inside the loop, but
at a performance hit) because it was trying to read the next row. When I
altered the loop I added a check before looking a row further, so it
shouldn't be happening along the bottom row anymore. However, the bottom
right pixel in an image (which is the final array location) will still try
to read one entry to the right, so will throw an exception. I suppose this
could also be checked for, but I did not add it because I'm pretty sure
that a per-pixel boolean check is more expensive overall than the few
exceptions that are caused by leaving it out. In any case when I tried it
the performance difference was not noticeable. On the other hand, the
check to get rid of the bottom row exceptions did, on the other hand, seem
to make a large difference.

So long story short, I think this bug is about as close to fixed as it's
going to get.

For reference's sake, in 0125 in PTriangle.java the relevant line is

if (ofs < lastRowStart) ofs+=TEX_WIDTH;

inside each of the drawSegment functions.

great, i'll close this one in that case.