Bug 1352 : Blurred PImages in OPENGL sketches (1.0.8)
Last modified: 2009-10-20 05:45



Assigned To:

Attachment Type Created Size Actions
This is a short simplified repro sketch that shows the problem text/plain 2009-10-20 02:11 1.29 KB

Description:   Opened: 2009-10-19 06:09
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)

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

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
Additional Comment #1 From fry 2009-10-19 20:50
hm, have you tried this on any other machines? (with different video cards,
different operating systems?)
Additional Comment #2 From threesixty3d 2009-10-20 01:08
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.
Additional Comment #3 From threesixty3d 2009-10-20 02:11
This is a short simplified repro sketch that shows the problem
Additional Comment #4 From threesixty3d 2009-10-20 02:37
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.
Additional Comment #5 From fry 2009-10-20 04:40
yep, this is all what i suspected. and yes, changing to a hint() is the plan.
Additional Comment #6 From fry 2009-10-20 05:19
removed NPOT code for 1.0.9 until it can receive further testing. right now
it's just important to have a stable release.
Additional Comment #7 From threesixty3d 2009-10-20 05:45
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.