rev. 0123

OPENGL mode misses one pixel in the upper right corner.
maybe the line (shape) is not closed?

F

edit]
sketch to show bug 501

one pixel of the outline (stroke) with rect() is missing in the upper right
corner.

this is the unfortunate doing of the same person who horked up the
tesselator. i've had it one the todo list, but now we've got an actual bug
filed for it.

I think this may be somewhat related to bug 95 - it has to do with the way
we decide whether a pixel is "hit" by a shape or not. OpenGL is _supposed_
to use the "diamond exit rule," but the specs actually leave it up to the
implementor to find something that's close to it. See
http://www.opengl.org/resources/faq/technical/rasterization.htm#rast0120
for another possibly relevant issue - it looks like OpenGL actually
requires DIFFERENT algorithms to decide whether to draw a pixel in filled
and stroked regions, which is a real effing mistake in my opinion...it
means that sometimes stroking and filling the same exact shape results in
different outline pixels being drawn.

in any case, the fix doesn't appear to be as simple as merely offsetting by
a _small_ epsilon - in my tests, it appears you actually need to offset by
about half a pixel to regain that pixel in the upper right:

//Press mouse button to regain corner pixel
import processing.opengl.*;
float EPS;
void setup(){
size(200, 200, OPENGL); EPS = 0;
stroke(0, 0, 255);
}
void draw(){
background(200);
if (mousePressed){EPS = .5;}
else{EPS = 0.0;}
rect(mouseX+20+EPS,mouseY-EPS, 50,50);
}

Don't know why you need to add to x coordinate and subtract from y, but it
seems to work. Of course, if you switch to P3D, you'll see that adding EPS
actually shifts the rectangle by a pixel...worse, in the default renderer,
it shifts the outline differently than it shifts the fill! I think it
might be pretty tricky to get this all working consistently, with each of
the renderers using different criteria for filling pixels; whatever the
solution, it will affect several current open bugs, so we really need to
figure out what the correct, desired behavior is. At the moment, I don't
think any of the three renderers do exactly what you'd expect.

you're correct, this is just a nasty consistency issue all the way around
(which is why i haven't gotten to fixing them.. heh) and just takes a good
bit of fighting with the code for a while.