Resizable Window has rendering Bug

[Benkralex]

Most appropriate sub-area of Processing 4?

Core/Environment/Rendering

Processing version

1295

Operating system

Linux Mint 22.1 x86_64; Kernel: 6.8.0-54-generic

Steps to reproduce this

1. Download Source Code from https://github.com/processing/processing4/releases/tag/processing-1297-4.3.4

2. Open Project in IntelliJ and run Ant Target Linux (See Picture in Additional context for Configuration)

3. Paste Code from the Example of setResizable() into the IDE and run (See Picture in Additional context)

4. Resize the window

snippet

void setup() {
  size(200, 200);
  surface.setTitle("Hello World!");
  surface.setResizable(true);
  surface.setLocation(100, 100);
}

void draw() {
  background(204);
  line(0, 0, width, height);
  line(width, 0, 0, height); 
}

Additional context

Would you like to work on the issue?

No

[Stefterv]

Hi @Benkralex I could not reproduce this on Ubuntu, could you please test the 4.4.1 beta with the distributed binary?

[Benkralex]

I tested 4.4.1 beta with IntelliJ
Run Config:

Same issue

I also tested to install the latest/beta 4.4.1 Version of the Snap Store, again same issue

[Stefterv]

Tested on a Linux Mint VM and seeing the same thing, switching to the P2D renderer fixes it so you could use that as a temporary fix until someone on real Mint can help us debug and fix this issue.

[chris-ti-an]

tested it with Processing (latest/beta 4.4.1) on Ubuntu 24.04.2 LTS

If I repeatedly resize the window for some time very quickly (large, small, large, ...), it takes a few seconds until it crashes and looks similar to the screenshots above.

[Stefterv]

Ah thank you @chris-ti-an, I suspect that is a different issue as on Mint it was instant, what you're describing is something we've also seen on Windows before

[SableRaf]

A simple resizeable sketch can also crash if the resizing is happening too fast.

Screen.Recording.2025-04-01.at.21.31.53.mov

Snippet

void setup() {
  size(500, 500);
  windowResizable(true);
  // allow the window to be resized
}

void draw() {
  circle(width / 2, height / 2, min(width, height) * 0.5);
  // draw a circle that resizes with the window
}

void windowResized() {
  println("Window resized to: " + width + "x" + height);
  // this function is called whenever the window is resized
}

[duskvirkus]

I am interested in looking at this. I'm planning to try to reproduce this bug and try to fix it this sometime this week. If anyone else is working on it let me know so we can coordinate.

[duskvirkus]

I was able to reproduce.

Spent a little while investigating seems like the AWTEvent here

processing4/core/src/processing/awt/PSurfaceAWT.java

Lines 992 to 1014 in ecd219b

	public void componentResized(ComponentEvent e) {
	// Ignore bad resize events fired during setup to fix
	// https://download.processing.org/bugzilla/341.html
	// This should also fix the blank screen on Linux bug
	// https://download.processing.org/bugzilla/282.html
	if (frame.isResizable()) {
	// might be multiple resize calls before visible (i.e. first
	// when pack() is called, then when it's resized for use).
	// ignore them because it's not the user resizing things.
	Frame farm = (Frame) e.getComponent();
	if (farm.isVisible()) {
	Dimension windowSize = farm.getSize();
	int x = farm.getX() + currentInsets.left;
	int y = farm.getY() + currentInsets.top;
	// JFrame (unlike java.awt.Frame) doesn't include the left/top
	// insets for placement (though it does seem to need them for
	// overall size of the window. Perhaps JFrame sets its coord
	// system so that (0, 0) is always the upper-left of the content
	// area. Which seems nice, but breaks any f*ing AWT-based code.
	int w = windowSize.width - currentInsets.left - currentInsets.right;
	int h = windowSize.height - currentInsets.top - currentInsets.bottom;
	setSize(w / windowScaleFactor, h / windowScaleFactor);

doesn't have the expected size values.

Rather interestingly while debugging if I left the sketch running for awhile (10-15 seconds) before resizing sometimes it would work as expected. However when I tried to reproduce this it was inconstant.

More debugging required but done for today.