[GTK] GC.copyArea from a display GC returns stale pixels at GDK_SCALE=2

未关闭
  • 哪里不对？
#3,685 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
java
领域
desktop

调研方向

Start from the GTK port's GC.copyArea(Image, int, int) implementation (the SWT GTK native/OS layer where gdk_cairo_set_source_window paints the root window), and compare it with the working gdk_pixbuf_get_from_window path plus how GDK_SCALE=2 scale factors feed the cairo source. Reproduce with the issue's snippet under Xvfb with GDK_SCALE=2 and 1. Done means the snippet returns current pixels at scale 2 while scale-1 behavior stays unchanged.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Java
星标
202
派生
206
平均合并
1 天 17 小时
30 天内合并 PR
109

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

eclipse-platform/eclipse.platform.swt 的其他 Issue

查看 eclipse-platform/eclipse.platform.swt 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。