[GTK] GC.copyArea from a display GC returns stale pixels at GDK_SCALE=2
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
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
- 平均マージ
- 14時間 7分
- マージ済み PR（30日）
- 103
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
eclipse-platform/eclipse.platform.swt のほかの issue
-
`SWT_AWT.initFrame` takes `(long, String)` in Java; the GTK native declares no `className` and the Cocoa native types it `const char *`対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
eclipse-platform/eclipse.platform.swt#3665 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
eclipse-platform/eclipse.platform.swt#3546 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
eclipse-platform/eclipse.platform.swt#3428 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1〜3時間 初心者へのやさしさ 75/100
eclipse-platform/eclipse.platform.swt#3336 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
eclipse-platform/eclipse.platform.swt#3718 ·
メンテナーはふだん 1 日以内に返信
eclipse-platform/eclipse.platform.swt の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
objectionary/lints#1556 ·
メンテナーはふだん 3 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
wildfly/wildfly-launcher#99 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
apache/rocketmq#11427 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
A failed JNA download is reported as a corrupt zip, because `curl` in `Makefile` lacks `--fail`オープン
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
objectionary/phino#1884 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信