Viewer under XWayland: MO Diagram window opens black; bottom strip blinks on property switches
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 43/100
Direzione di ricerca
Start by tracing the MO Diagram window creation and the property-switch path that calls wxAuiManager::Update(), then reproduce both artefacts on GNOME Wayland under XWayland with the scripted clicks and window grabs described in the issue. Compare approaches that avoid unnecessary pane updates or reuse/dock the floating window; done means neither the initial black window nor the blinking bottom strip appears.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Two short redraw artefacts remain on GNOME Wayland (ECCE on XWayland, NVIDIA 550), both measured on the affected desktop with scripted clicks and window grabs:
- MO Diagram window black on first opening. The floating window is black for about 100–200 ms after it appears (grabs at 11, 51 and 89 ms black, content from about 180 ms). Building the diagram after the window had painted (CallAfter) and keeping the window transparent until the first paint (SetTransparent) did not remove it: the window is put on screen before GTK paints into it.
- Bottom strip blinks on every property switch. For one frame, the Rotation row and the Log caption are replaced by blank grey while wxAuiManager::Update() re-lays the panes out. Freezing the frame during the update (as BuilderRedrawHold does on Windows) made it a black blink instead and was reverted.
Both are probably the same cause: with GTK frame sync off under XWayland (needed so dialogs repaint), intermediate states reach the screen. Possible directions: re-lay out only when the layout really changes (a property switch in list + detail mode need not run a full Update()); for the floating window, create it once and keep it, or dock the MO Diagram instead of floating it.
- Lingua principale
- C
- Stelle
- 10
- Fork
- 8
- Merge medio
- 21m
- PR unite (30g)
- 1
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di FriendsofECCE/ECCE
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
FriendsofECCE/ECCE#336 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
FriendsofECCE/ECCE#363 · 3 commenti ·
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
FriendsofECCE/ECCE#362 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
FriendsofECCE/ECCE#359 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 28/100
FriendsofECCE/ECCE#358 ·
Tutte le issue di FriendsofECCE/ECCE
Issue simili
-
Weekly fuzz run failedAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
kubernetes-sigs/security-profiles-operator#3597 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
AFLplusplus/AFLplusplus#2903 ·
-
Clean up stale and inaccurate comments in the platform screen and input filesForse già presa @RichStephens l’ha presa oggi. Aperta
Difficoltà 2/5 Mezza giornata Idoneità per principianti 88/100
FujiNetWIFI/fujinet-config#289 ·
I maintainer di solito rispondono entro 1 giorno
-
[raylib] update to 6.2Apertacategory:port-update
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 90/100
nasa/cFS-GroundSystem#272 ·