[GTK][X11] Drawing on an image is shifted with DPI scaling
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- java, linux
- Área
- desktop-dev
Línea de trabajo
Start by running the supplied Java reproduction with GDK_BACKEND=x11 and GDK_SCALE=2, then read the SWT Image and GC drawing APIs and trace their Linux/X11 DPI handling. Compare the repainted image with the original; done means the drawing is correctly aligned at scaled DPI, with only the red rectangle added.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug
Drawing on an Image object using a GC is shifted by a significant amount when run on X11 with DPI scaling.
To Reproduce
The following program executed on Linux with either full X11 session or in wayland with Xwayland.
To reproduce:
- Set the GDK_BACKEND=x11 and GDK_SCALE=2 environment variable. The latter was not required on my system, the OS-level scaling was automatically detected and applied with the same result as setting the environment variable.
- Start the program.
package test;
import org.eclipse.swt.SWT;
import org.eclipse.swt.graphics.Color;
import org.eclipse.swt.graphics.GC;
import org.eclipse.swt.graphics.Image;
import org.eclipse.swt.graphics.ImageData;
import org.eclipse.swt.graphics.PaletteData;
import org.eclipse.swt.graphics.Rectangle;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Shell;
public class Test
{
private static Image repaint( Image source )
{
Rectangle bounds = source.getBounds();
Image newImage = new Image( source.getDevice(), bounds.width, bounds.height );
GC gc = new GC( newImage );
gc.setAntialias( SWT.ON );
gc.setInterpolation( SWT.HIGH );
int offset = 0;
// offset = bounds.height * ( DPIUtil.getDeviceZoom() - 100 ) / 200;
gc.drawImage( source, 0, 0, bounds.width, bounds.height, 0, offset, bounds.width, bounds.height );
gc.setForeground( new Color( source.getDevice(), 0xff, 00, 00 ) );
gc.drawRectangle( 0, offset, bounds.width - 1, bounds.height - 1 );
gc.dispose();
return newImage;
}
public static void main( String[] args )
{
Display dpy = new Display();
ImageData imageData = new ImageData( 256, 256, 24, new PaletteData( 0xff0000, 0x00ff00, 0x0000ff ) );
for ( int i = 0; i < 256; ++i ) {
for ( int j = i % 16; j < 256 - i % 16; ++j ) {
imageData.setPixel( i, j, ( i << 8 ) + j );
}
}
Image image = new Image( dpy, imageData );
Shell shell = new Shell( dpy );
shell.setText( "SWT " + SWT.getVersion() );
Label label1 = new Label( shell, SWT.NONE );
Label label2 = new Label( shell, SWT.NONE );
label1.setSize( image.getBounds().width, image.getBounds().height );
label1.setImage( image );
image = repaint( image );
label2.setBounds( label1.getBounds().width, 0, image.getBounds().width, image.getBounds().height );
label2.setImage( image );
shell.setSize( label1.getBounds().width + label2.getBounds().width,
Math.max( label1.getBounds().height, label2.getBounds().height ) );
shell.open();
while ( !shell.isDisposed() ) {
if ( !dpy.readAndDispatch() ) {
dpy.sleep();
}
}
dpy.dispose();
}
}
Expected behavior
The re-painted image on the right side should look the same as the one on the left (except for the added red rectangle).
Screenshots
Environment:
- Select the platform(s) on which the behavior is seen:
-
- All OS
-
- Windows
-
- Linux
-
- macOS
-
Additional OS info (e.g. OS version, Linux Desktop, etc)
Observed on Kubuntu 24.04 and 26.04 on both Xwayland and native X11 server -
JRE/JDK version
java-25-openjdk-amd64
Version since
The last version which shows the expected behavior is 4.7.3a:
In SWT 4.8 - 4.16 the image is smaller and shifted vertically:
In SWT 4.17 and newer it is not smaller but it is shifted by the amount relative to the DPI scaling:
Workaround (or) Additional context
I was able to workaround the issue in SWT 4.17 and later by shifting the drawing coordinates by amount proportional to the UI scaling (visible in the code snippet as a commented-out line). The workaround works for different scaling values between 1 and 5. SWT 4.8 - 4.16 would likely require a different shift value(s).
- Lenguaje dominante
- Java
- Estrellas
- 202
- Forks
- 206
- Merge medio
- 14 h 7 min
- PR fusionados (30 d)
- 103
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de eclipse-platform/eclipse.platform.swt
-
`SWT_AWT.initFrame` takes `(long, String)` in Java; the GTK native declares no `className` and the Cocoa native types it `const char *`Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
eclipse-platform/eclipse.platform.swt#3665 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
eclipse-platform/eclipse.platform.swt#3546 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
eclipse-platform/eclipse.platform.swt#3428 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 75/100
eclipse-platform/eclipse.platform.swt#3336 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
eclipse-platform/eclipse.platform.swt#3718 ·
Los mantenedores suelen responder en 1 día
Todos los issues de eclipse-platform/eclipse.platform.swt
Issues similares
-
:ml/Transform >bug Team:ML
Dificultad 2/5 Medio día Aptitud para principiantes 64/100
elastic/elasticsearch#161960 · 2 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
chore: update release scheduleAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
objectionary/lints#1556 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
wildfly/wildfly-launcher#99 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
apache/rocketmq#11427 · 2 comentarios ·
Los mantenedores suelen responder en 1 día