i don't remember P3D being this bad at textures, but at least in 124 and
125, text rendering is bad enough (even without any sort of scaling) that
it's not even usable.

size(300, 300, P3D);
background(255);
fill(0);
textFont(createFont("SansSerif", 12));
text("Testing 123", 10, height/2);

just in case you have any ideas about this one...

Yup, I'll take a look - I have checked into this before, and if I recall it
was something about the filtering causing problems, so I'll play around a
bit more. The subpixel shifting I added in 0125 may have altered this a
bit, but it is still a problem without it in 0124, so... Did something
change between 0123 and 0124 regarding that stuff that might have triggered
these problems? I only started dealing with the source in 0124, so I'm not
sure myself.

i may be mistaken, and it's simply always been that bad... i was just
surprised that without any scaling or manipulating, the text is a mess. in
the past i've used textMode(SCREEN) so maybe i've ignored it. i probably
just haven't tried to do text with P3D for a while ;)

Yeah, it's definitely the filtering - in PTriangle.java, try going to the
setTexture(PImage) function, and down at the bottom of the function change
m_bilinear to false (line 421 in my file). Text becomes nice and crisp again.

I'm actually a bit suspicious of the filtering code in PTriangle, because
it seems overly sensitive to very small changes in positioning, which
doesn't seem like it should be the case. But it's all fixed point stuff
that I'm going to need to sit down and go through in detail to see if
there's an actual problem or not. It's funny, this stuff really isn't
noticeable when you're dealing with pictures or anything like that, in
fact, I've never noticed a problem except for text, but that must just be
because we're more sensitive to the tiny details there.

For now, unless we can track down a real solution to this problem, we could
simply turn off filtering when drawing text.

yeah, well don't give it too much effort.. the point of P3D is to quickly
draw shapes in 3D, with a significant tradeoff in quality. when P2D comes
back it won't be an issue, so it's not particularly worth your time, was
just curious if it seemed like a regression or if there's something dumb
that is happening right off the bat. not worth re-engineering anything tho.

Well, just changing a check if we're currently drawing a text character
(say just by setting a flag in PGraphics) and setting m_bilinear to false
if so should help a bit, though it's not necessarily perfect, and for
fractional displacements of the text the text still looks a bit weird. If
you want to try this, add the new variable

static public boolean drawingText = false;

to PGraphics, and around line 2855 or so, wrap the imageImpl call as follows:

drawingText = true;
imageImpl(glyph, x1, y1, x2, y2, 0, 0, u2, v2);
drawingText = false;

Then in PTriangle.java change line 421 (or so, not sure if I've made
changes to my file or not) to:

m_bilinear = PGraphics.drawingText?false:true;

If I'm correct, this should turn on filtering when we're drawing a normal
image, and off when we're drawing text. The improvement is quite
noticeable in your test case. [This probably isn't the cleanest/safest way
to access that boolean, btw, it just seemed like the easiest way to try it
out for now.]

But really, if people want small, perfect text, they should use
textMode(SCREEN) and be done with it. Another workaround (for those that
might want to rotate or otherwise transform their text) is to create fonts
that are larger - I found that if you create a font at size 24 or 48
instead of 12, the problem is far less visible, even if you ultimately draw
the text smaller. All of this really stems from a slightly improper
handling in the renderer of edge pixels, which is submitted as another bug
somewhere else and is a bit more difficult to fix. So if the textures you
use don't depend on the border pixels, you're always going to be better off
as a rule in P3D.

This has been essentially handled at
http://dev.processing.org/bugs/show_bug.cgi?id=466 - Ben, what I'm thinking
is that maybe this bug (611) should be closed and 466 left open but lowered
in priority, as there is still a filtering issue causing images to be
slightly off, but the fix I posted there is a decent workaround to fix
text, which is where the most pain was coming from (edge pixels on most
images are usually not critical unless you're rendering text with a very
tight bounding box).

*** This bug has been marked as a duplicate of 466 ***