1. 0161 beta
2. OS X 10.5.5, MacbookPro2,2
3. Smallest piece of code
[code]

import processing.opengl.*;
void setup() {
size(400,400,OPENGL); // with OPENGL
//size(400,400); // without
}
void draw() {
rect (mouseX,mouseY,20,20);
}

[/code]

Different behaviour in P3D and OPENGL of background redrawing. in OPENGL it
always clear background

as already noted in other bug reports, stroke color and aspect also differ
in both renderers

what happens if you use hint(DISABLE_OPENGL_2X_SMOOTH) right after size()?

does it clear the background each time, or is it just flickering?

what video chipset is macbookpro2,2? is that the radeon 1300?

Chipset Model: ATY,RadeonX1600
using this hint command bring things back to normal (function and appearence)
cheers

Got the same problem:

Processing 1.0.1
Windows XP (SP2)
ATI Mobility Radeon X1400

Trying hint(DISABLE_OPENGL_2X_SMOOTH) didn't work :-/

Processing 1.0.4
Windows Vista
Mobile Intel 4 Graphics (Laptop Integrated)

I can add a rather interesting development to this:

Step 1) Enable "Aero" theme.
The sample code in post 1 runs with no flickering.

Step 2) Enable "Vista Basic" theme
The sample code in post 1 runs with flickering, like the user above (essentially, this is
XP behavior.)
Also like the above poster, hint(DISABLE_OPENGL_2X_SMOOTH) does not affect the
flickering here.

Also, my XP in the other room has always flickered.

I did some research, the closest thing I found was OPENGL-Python bindings also
having this Flickr problems on winXp due to Radeon cards that they fixed by
overriding OnEraseBackground, but that doesn't translate.

I.E., I have no idea. If someone is desperate enough, there is a way to copy the
whole frame buffer inside OPENGL into another TextureBuffer, and then redraw it the
next frame: it's not that slow if you don't try to bring it back to the java-pixel level.

-Taif out. who really liked the idea of drawing on top of the last frame anyway?

this is a problem with some video card drivers, particularly the cheaper
integrated chipsets, but also present on some nicer cards. usually newer
drivers fix the problem, but it's outside of something that we can fix.

yeah, completely scratch what I wrote, fry. I just tested this on a relatively old win XP, but
with a NICE NICE graphics card. It worked just like p3d.

So... yeah, way outside of our control.

Adding hint(DISABLE_OPENGL_2X_SMOOTH) alone didn't work for me, but these
two together did:

hint(DISABLE_OPENGL_2X_SMOOTH);
hint(DISABLE_DEPTH_TEST);

Macbook Pro, Radeon X1600, OSX 10.5.8

The problem here is that it's based on the number of buffers available to
OpenGL. So if you have a limited graphics card or high screen resolution or
something that's using up all your video memory, you can't get access to
certain features. As a result, OpenGL just gives up on some of it. There
isn't a way for us to detect when it actually happens, or what the results
will be, because it's all undefined and driver-specific.