Repository navigation
[GTK] GC.copyArea from a display GC returns stale pixels at GDK_SCALE=2 #3685
Description
On GTK with GDK_SCALE=2, GC.copyArea(Image, x, y) on a display GC returns the first read of a screen area again for every later read of the same area.
A shell opened after the first read is missing from the copy, and a shell closed later stays in it.
A read of a different area is current, and gdk_pixbuf_get_from_window on the root window returns the current pixels for the same area.
At scale 1 everything is current.
Snippet:
Display display = new Display();
Shell red = new Shell(display);
red.setBackground(display.getSystemColor(SWT.COLOR_RED));
red.setBounds(0, 0, 1000, 700);
red.open();
pump(display, 1500);
copy(display); // red, as expected
Shell blue = new Shell(display);
blue.setBackground(display.getSystemColor(SWT.COLOR_BLUE));
blue.setBounds(100, 100, 400, 300);
blue.open();
pump(display, 1500);
copy(display); // pixel at (200,200) is still red, expected blue
static void pump(Display display, int millis) throws InterruptedException {
long end = System.currentTimeMillis() + millis;
while (System.currentTimeMillis() < end) {
if (!display.readAndDispatch()) {
Thread.sleep(10);
}
}
}
static int copy(Display display) {
Image image = new Image(display, 1000, 700);
GC gc = new GC(display);
gc.copyArea(image, 0, 0);
gc.dispose();
ImageData data = image.getImageData(display.getPrimaryMonitor().getZoom());
image.dispose();
return data.getPixel(400, 400);
}Seen on Linux X11 (Xvfb 3200x2000, dpi 192, GDK_SCALE=2) with the SWT of Eclipse 4.41 (2026-09).
Waiting, flushing and marking the GC's cairo target dirty do not help.
copyArea(Image, int, int) paints the root window through gdk_cairo_set_source_window, which looks like the cached path.
Reading through gdk_pixbuf_get_from_window instead works around it.
Activity
Capture the screen through GDK's pixbuf read at 200%