Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Win32] GC.getClipping(Region) loses the window origin in advanced mode on a double-buffered paint GC

Abierto
  • ¿Algo no está bien?
#3,528 0 comentarios 0 reacciones 0 asignados Ver en GitHub

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
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
java
Área
desktop

Línea de trabajo

Start by tracing Composite.WM_PAINT and GC.getClippingRegion() alongside initGdip(); the issue identifies the window-origin and clipping-coordinate mismatch in the double-buffered advanced-mode path. Reproduce with the reported CTabFolder paint scenario, then verify that saving and restoring clipping through a Region leaves getClipping() unchanged in both advanced and non-advanced modes.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

On Windows, once the paint GC of a SWT.DOUBLE_BUFFERED control is in advanced graphics mode, set explicitly or implicitly by setAlpha/setAntialias, getClipping(Region) disagrees with getClipping(). The region is short by the window origin that the double buffering installed and initGdip() removed, so saving and restoring the clipping through a Region shrinks the clip and clips away everything drawn afterwards.

Composite.WM_PAINT calls SetWindowOrgEx(hdc, ps.left, ps.top). initGdip() then does SelectClipRgn(handle, 0) and the GDI+ graphics takes over the DC transform, after which GetWindowOrgEx is (0,0). GC.getClippingRegion() offsets by that lost origin, while the region held by GDI+ is still in the buffer's coordinates.

Measured (real CTabFolder paint, 150% zoom, damage {74,0,188,23}):

advanced=false  getClipping()={74,0,188,23}  windowOrg=(111,0)  round-trip exact
advanced=true   getClipping()={74,0,188,23}  windowOrg=(0,0)
                getClipping(Region) for {96,0,166,23} -> {96,0,92,23}   short by 74
                after restore: getClipping()={74,0,114,23}

Expected behavior

A getClipping(Region)/setClipping(Region) round-trip is lossless and agrees with getClipping(), regardless of the GC's advanced mode.

Environment

Windows 11 Home 10.0.26200, 150% zoom (also seen at emulated 100%).

Additional context

Found while fixing #3522. That fix avoids advanced mode for the rest of the paint and so dodges this defect, but does not repair it. Any code that switches a double-buffered paint GC to advanced mode and saves/restores clipping via a Region is exposed.

No standalone Canvas reproducer yet: a SWT.DOUBLE_BUFFERED Canvas came back lossless in both modes because that paint never took the buffered code path. The trace above is from a real CTabFolder paint.

Lenguaje dominante
Java
Estrellas
202
Forks
206
Merge medio
14 h 7 min
PR fusionados (30 d)
103

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eclipse-platform/eclipse.platform.swt

Todos los issues de eclipse-platform/eclipse.platform.swt

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.