Bug 1054 : background redrawing in OPENGL
Last modified: 2009-09-14 09:32



Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2008-11-24 17:07
1. 0161 beta
2. OS X 10.5.5, MacbookPro2,2
3. Smallest piece of code

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


Different behaviour in P3D and OPENGL of background redrawing. in OPENGL it
always clear background
Additional Comment #1 From Dimitre 2008-11-24 17:08
as already noted in other bug reports, stroke color and aspect also differ
in both renderers
Additional Comment #2 From fry 2008-11-24 17:12
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?
Additional Comment #3 From Dimitre 2008-11-24 17:14
Chipset Model: ATY,RadeonX1600
using this hint command bring things back to normal (function and appearence)
Additional Comment #4 From fxb 2009-01-22 08:30
Got the same problem:

Processing 1.0.1
Windows XP (SP2)
ATI Mobility Radeon X1400

Trying hint(DISABLE_OPENGL_2X_SMOOTH) didn't work :-/
Additional Comment #5 From taifunbrowser 2009-06-21 19:19
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?
Additional Comment #6 From fry 2009-06-25 14:04
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.
Additional Comment #7 From taifunbrowser 2009-07-06 15:40
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.
Additional Comment #8 From mungbean 2009-09-13 15:13
Adding hint(DISABLE_OPENGL_2X_SMOOTH) alone didn't work for me, but these
two together did:


Macbook Pro, Radeon X1600, OSX 10.5.8

Additional Comment #9 From fry 2009-09-14 09:32
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.