Program "crashes" when I setResizable(true) and resize the Window

Processing
1

This is my code

void setup() {
  size(1920, 1080);
  surface.setResizable(true);
}
void draw(){
  background(0);
  fill(255);
  rect(0,0,width,height);
}

When I change my window size to be as small as possible then resize it to a normal size it breaks. What I mean by that I can still move the Canvas and resize it but the draw method stops looping and WindowResize() isn’t called anymore when the window is resized. I’m on window 10 intel and I’m on version 4.2. I haven’t seen Any post about this issue before so any help would be great!

Here is a video of it happening if u want too see:
Drive link to Video

1 Like
2

I tried your code using Processing 4.2 on my iMac and it worked without issue. Perhaps it is just with Windows.

3

Interesting that’s it’s platform based. It does only happen if I go as small as I can. So if there was a way to increase that minimum width and height it might fix it.

4

I doubt if that would make any difference. It is more likely the problem was caused by trying to reduce the window size to below the permitted minimum width and height rather than their actual value.

I tried reducing the window size below minimum size also tried and minimising / maximising the window all worked just fine.

5

That does make more sense, do you have any ideas to fix it?

6

Since it works on my imac there seems to be 2 possibilities

  1. It is platform specific i.e. related to Windows version of Processing
  2. Something specific related to your system.

If other Windows users try out your code and get the same problem then it might be (1) if they have no problems then (2). Since I am not using Windows and I can’t reproduce the problem I can’t really help further. Good luck.

7

I’m unable to reproduce this with Windows11. There is some lag of the rectangle when the window is resized but it always comes back to the window width and height. Naive question: Why don’t you just make the window background white (and forget the rectangle)?

I just noticed that your movie was made with an additional line of code where you println() the frameCount; what happens when you take that line out? I tried adding that line to the Windows11 code and it still works as expected.

8

I was able to test My code on another machine which is also running windows 10, it does still break but it’s still weird that the bug is fixed on windows 11. @svan This isn’t a Naive Question, This isn’t my actual program, I have alot of elements updating them selves based on the public variable width and height which isn’t being updated because of this bug. Also println() is just telling me if the program is still calling draw() which you could see in the video that it wasn’t. If I remove it, it doesn’t impact the result.

Thx for your Help @quark I guess I’ll have to find some way to detect the bug and fix it. If I come up With a solution I will post it in this forum, and anyone with any ideas of potential fixes plz let me know.

Thx in Advance

9

Does this break?

void setup(){
 size (320, 240);
 surface.setResizable(true); 
 rect(0, 0, width, height);
 noLoop();
}
10

@svan This is a solution for the problem but in the program I need to use draw() on loop() which breaks the solution. Any other Ideas?

11

I have just figured out that the time that it breaks it doesn’t call windowResized() which is very odd

12

There is also a windowResize(newWidth, newHeight); does calling that in each loop of draw() help?

void setup() {
  size(400,400);
  surface.setResizable(true);
  background(0);
}

void draw() {
  windowResize(width, height);
  rect(0,0,width,height);
}
13

@svan Sadly it doesn’t help cause when the bug happenes sit doesn’t call draw anymore

14

Is this usable:

void setup() {
  size (320, 240);
  surface.setResizable(true);
  background(0);
}

void draw() {
  fill(255);
  rect(0,0,width,height);
  noLoop();
}
15

no I need draw to loop

16

it doesn’t help cause when the bug happenes sit doesn’t call draw anymore

This is the first time I’ve ever heard of draw() stalling. Someone can correct me if I’m wrong but I thought that the loop() was based on some little vibrating crystal in the guts of a computer, the ‘internal clock’. I just can’t imagine that failing. I think there is a battery somewhere that keeps it powered up.

17

the program is crashing so the draw method is not able to be called

18

and also I’m pretty sure that’s not how draw() works

19

We need to hear from more Windows 10 users. There should be quite a few in this forum. The source code looks pretty innocuous and it’s difficult to believe it causes a ‘crash’ or even a ‘freeze’. It will be interesting to see what happens on other Win10 systems.

To me a ‘crash’ is when the window disappears and you have nothing to work with. In your case it looks to me more like a ‘freeze’ or a ‘hang’. Processing’s runtime appears to have stopped processing instructions. A ‘stack trace’ with a debugger should show what caused it to ‘hang’ but unfortunately I have no idea how that could be done with a regular Processing app.

20

I’m pretty sure that’s not how draw() works

How do you think it works? Something has to provide the timing (default 60 frames/sec).