Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#3,528 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
java
Ambito
desktop

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
202
Fork
206
Merge medio
14h 7m
PR unite (30g)
103

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eclipse-platform/eclipse.platform.swt

Tutte le issue di eclipse-platform/eclipse.platform.swt

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.