when one resizes a window in OPENGL, all graphics then drawn incorreectly (both their scale
and their position).
below is a simple example of a box that is suddenly drawn larger and larger the smaller one
makes the window, with its insertion point and aspect ratio getting messed up.


processing 1.01
mac osx 10.5.5

------

import processing.opengl.*;

void setup(){
size(1200,800,OPENGL);
frame.setResizable(true);
}

void draw(){
background(0);
rect(20,20,600,600);
}

This actually happens in all platforms and all versions of Processing after
1.0.

The distortion is due to the fact that the applet "thinks" it has resized:
the width and height variables are updated, but the actual size does not
change onscreen.

In the example below, you are drawing a 600x600 rectangle on a 1200x800
window. Now imagine you resize the window to 2400x800. The applet remains
the same size on the screen, but it thinks that there are 2400 pixels in
the original frame, so the rectangle will be compressed to an effective
300x600 pixels.

Here's a more elaborate example that explains that behavior


import processing.opengl.*;

void setup() {
size(310,310,OPENGL);
PFont myFont = createFont("Sans", 16);
textFont(myFont);
frame.setResizable(true);
}

void draw() {
background(10);
stroke(153);
noFill();
rect(1,1,width-3,height-3);
fill(150);
for (int i=0;i<width;i+=10) {
int h;
if (i % 100 == 0) h = 20;
else if (i % 50 == 0) h = 10;
else h = 5;
line(i,10,i,h+10);
}
for (int i=0;i<width;i+=100) {
if (i==0) textAlign(LEFT);
else textAlign(CENTER);
text(""+i,i,30);
}
textAlign(RIGHT);
text("Current Size = "+width+"x"+height,width-15,height-20);
}

Here's a possible patch to fix this problem; it seems to work fine in Linux
but not on my old G4 iBook. I don't know enough OpenGL to be able to tell
if this is the right thing to do.

In method allocate in PGraphicsOpenGL v.5494 after else { (line 198) add
the following:


context.destroy();
context = drawable.createContext(null);
gl = context.getGL();


The rationale being: the old context has the wrong size. We replace it with
a new context; the new context takes on the size of the containing panel.

> context.destroy();
> context = drawable.createContext(null);
> gl = context.getGL();

It seems to work correctly! Yey!
P5.Resize is back in my life!
;)

Tested on XP, with Pv1 with Opengl 5494, GeForce NVIDIA.
Resizing does NOT work and the system becomes very unstable, very slow.

(In reply to comment #5)
>
>
>
> Additional Comment #5 From
> gll
> 2009-04-30 01:03
>
>
> addReplyLink(5); //-->[reply]
>
>
>
>
> > context.destroy();
> > context = drawable.createContext(null);
> > gl = context.getGL();
>
> It seems to work correctly! Yey!
> P5.Resize is back in my life!
> ;)
>
>

I've forgotten; the previous test was good and is still working perfectly.
It was an another machine (Ubuntu, NVIDIA FireGL, P5V1).
This is one is correct.

k, i've applied that patch for 1.0.4. thanks!

The proposed fix (now public) has a major side effect: Destroying the context means
that all images, textures, and shaders must be reloaded. That's tough to work around
.

I think all we need really is a

glViewport(0, 0, width, height);

, then re-applying the user's perspective and camera matrices.
*(That's what the NeHe tute suggests:
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=01
)

Sorry for being such a bug-Taif

Hey Taif,

I tried that line but was unable to make it work. Possibly because I am not
familiar with OPENGL at all.

Pablo.

(In reply to comment #9)
>
>
>
> Additional Comment #9 From
> taifunbrowser
> 2009-06-21 18:34
>
> <!--
> addReplyLink(9); //-->[reply]
>
>
>
>
> The proposed fix (now public) has a major side effect: Destroying
the context means
> that all images, textures, and shaders must be reloaded. That's tough to
work around
> .
>
> I think all we need really is a
>
> glViewport(0, 0, width, height);
>
> , then re-applying the user's perspective and camera matrices.
> *(That's what the NeHe tute suggests:
> http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=01
> )
>
> Sorry for being such a bug-Taif
>
>

actually, can you please file a new bug for that, since it's a separate
problem/regression from the previous issue?