This bug has been found on a OpenGL sketch.

Here's a comparison of the same applet (same libs, same source, same
everything, running on 1.0.7 vs 1.0.8)
http://www.threesixty3d.com/tmp/p5_108_blurry_textures.jpg

This is a 3D pure OpenGL app (no P3D) with controlP5 on top of it. It uses
also 2D PImages composited on top of everything for additional interface
components.

It runs fine on 1.0.7, but gets all blurry on 1.0.8.
PImages and P5 bitmap fonts are getting blurred too.

The app uses also 2D textures (PImages uploaded to the gpu, with or without
mipmaps) which are rendered with the correct sharpness, so it's not a
driver / gpu bug.

I cant be sure, but it looks like all textures handled by processing (POT
and NPOT) are being resized for no reason.

Software/Hardware: XP Professional ENG SP3 x86 - Intel Quadcore Q6600 -
NVidia Geforce FX 8400 HD with NVIDIA drivers installed, including the cuda
driver v2.2

hm, have you tried this on any other machines? (with different video cards,
different operating systems?)

You're right, this is happening on the NVidia Geforce FX 8400 (opengl
3.0.0) but not on the Intel GMA 950 (opengl 1.4.0), which is a cheap
integrated card.

I've noticed in http://www.processing.org/download/revisions.txt that 1.0.8
"Implements non-power-of-2 textures for OpenGL (on cards where available)."

After this I'm almost sure that it's the source of the problem, as the
Geforce is quite recent and supports GL_ARB_texture_non_power_of_two, while
the cheap one does not (ext got into core with gl 2.0 i think).
I'd suggest to leave the NPOT support as an hint() or as a parameter for
loadImage(), cause forcing it doesnt look good for the PImages being used
for drawing interfaces on top of the 3D, like controlP5 for instance.

edit]
This is a short simplified repro sketch that shows the problem

I've posted a short simplified repro sketch that shows the problem.

To test it, I guess you need a card that supports NPOT or ogl 2.0+
If you dont have controlP5 installed, just comment the lines that relate to it.

POT square textures are handled correctly.
POT rectangles textures are blurred and NPOT textures are blurred.
Maybe the eames.jpg is not the best texture to test it on, as it's already
a bit blurry on his own, but you can definitely see this if you check it
with photoshop using "difference" as transfer mode, overlaying the p5
render with the original jpg.

Btw I tried to do the same thing sometime ago (PImage::resize() to
power-of-two all NPOT textures to gain some rendering speed) and ... it's
just not good.
All OpenGL 2.0+ cards have good NPOT hardware support, so you wont gain
noticeable improvements. Older cards most commonly dont have the extension
at all and that's where the resize might be handy, but it still looks ugly.

I also tried to create a null buffer with glTexImage2D() passing, for
example, 256, 256 as width/height of a 197x197 square texture, and after
that uploading the real pixel buffer using glTexSubImage2D() with the
actual dimensions.
It works, but it's not good either because you might need to set
GL_TEXTURE_WRAP to GL_REPEAT, causing artifacts when the texture is tiled.

Well anyways ... to sum it up, I just think it's better to leave this to
the user, either with a hint() flag or as a loadImage() parameter.

yep, this is all what i suspected. and yes, changing to a hint() is the plan.

removed NPOT code for 1.0.9 until it can receive further testing. right now
it's just important to have a stable release.

True. One last thing though.

PImages are used both as 2D Images and Textures for P3D / OpenGL, each with
different purpose and characteristics.
Right now it's possible to mix the two things, for example by drawing a 2D
Interface on top of a PGraphicsOpenGL Buffer using image() calls.

Because of this, a hint() might not be a good choice, as it would act as
global switch, meaning that you can use all PImage objects either only as
textures for 3D or only as 2D pictures.

Btw I must be missing something ... what are you looking to achieve
exactly? I ask this because resizing NPOT textures ONLY on hardware with
GL_ARB_texture_non_power_of_two support doesnt make much sense to me, as
the hw already supports it.