Bug: Windows overlap while resizing, until slower apps catch up

Abierto
#565 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@mattchristenson ya está trabajando en esto.

Desde el 30/9/2026.

  • #570 de @mattchristenson — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
30/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
javascript, linux
Área
desktop-dev

Línea de trabajo

Run sandbox/run-suite.sh 18 from forge-repro to observe overlap episodes per scenario. Acceptance criteria require no tiled overlap at any frame. The linked PR #570 already implements a fix, so pick up from there rather than starting fresh; no forge source file is named in the issue.

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

Descripción

Problem. When Forge changes the layout (a window opens or closes, a container is resized), it asks every affected window for its new place at the same moment. Apps take a frame or more to draw their new size, and GNOME keeps showing a Wayland window at its old place and size until the app has drawn it. X11 apps, by contrast, move at once. So a window that grows into the space its neighbour gives up is drawn over that neighbour until the neighbour has redrawn.

Usually that is one to three frames. While a resize key repeats, Forge sends a new place before the app has drawn the last one, and GTK apps (Ptyxis, Files, Text Editor) fall behind by up to about a second. Example: hold Super+Ctrl+Left on a window with a terminal to its left and VS Code below it. VS Code (X11) follows every step at once, and the terminal lags, so VS Code covers the terminal by hundreds of pixels for seconds.

holding a resize key next to a slow app: the fast window covers the slow one; with the fix it waits

Desired outcome. A layout change never shows one tiled window on top of another. While an app catches up there may be a gap (the wallpaper shows briefly), never an overlap. The final layout and the speed of resizing are unchanged.

Acceptance criteria.

  • Holding a resize key between a GTK app and an X11 app: no overlap at any moment, and no check on the layout reported by GNOME fails.
  • Opening, closing and moving windows: no overlap longer than one frame.
  • A window whose app never redraws doesn't hold the others back for more than half a second.
  • Windows that swap places (move left/right) still swap immediately.
  • All layout scenarios still pass.

Reproduction: scenarios/18_slow_redraw_overlap.py, which uses a test app that takes 120 ms to follow each new size, next to a fast window. Or, with real apps, scenarios/07_real_apps.py (7v.4) on a large screen. sandbox/run-suite.sh 18 also reports every overlap episode per scenario.

Lenguaje dominante
JavaScript
Estrellas
1.3k
Forks
112
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 forge-ext/forge

Todos los issues de forge-ext/forge

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.