Éditeur de scène : le canevas remplit exactement l'espace disponible, plus de marges

Le calcul JS "object-fit:contain" du tour précédent gardait l'aspect-ratio
(Portrait/Paysage/Carré) au prix de marges vides sur les côtés dès que la
fenêtre n'avait pas exactement ce ratio - "prendre toute la place
disponible" et "garder l'aspect-ratio" sont deux exigences contradictoires
dans ce cas, et c'est la première qui doit l'emporter dans l'éditeur.

Le canevas (#canvas) remplit donc maintenant .canvasFrame à 100% x 100%,
sans plus tenir compte de l'aspect-ratio choisi dans l'éditeur - ce
réglage continue de s'appliquer normalement à l'aperçu jouable ("Jouer",
voir screen_set_aspect.py/play.html), qui reste la référence pour le
rendu final. Padding de .canvasFrame réduit au minimum. fitCanvasToFrame()
et son calcul en pixels n'ont plus lieu d'être - retirés entièrement.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
william
2026-08-25 11:50:50 +02:00
co-authored by Claude Sonnet 5
parent 14deba943a
commit 11b08c8503
2 changed files with 18 additions and 56 deletions
+14 -18
View File
@@ -244,26 +244,22 @@ body.builderBody > main.content{ flex:1 1 auto; min-height:0; overflow:hidden; d
.canvasFrame{
/* flex:1 1 auto + min-height:0 : occupe tout l'espace restant sous la
barre d'outils dans .builderTabPanel (voir screen_edit.html), et c'est
LUI qui défile (overflow:auto) si le canevas ne peut pas être réduit
davantage (ex. fenêtre très basse) — jamais .builderCanvasArea (voir
plus haut), pour garder la barre d'onglets/d'outils toujours visible. */
flex:1 1 auto; min-height:0; width:100%; padding:10px; border:1px solid var(--border); border-radius:16px; background:var(--panel);
display:flex; align-items:center; justify-content:center; overflow:auto;
barre d'outils dans .builderTabPanel (voir screen_edit.html). Le
canevas (voir .canvas ci-dessous) est réglé pour remplir EXACTEMENT
ce cadre (100% x 100%, sans respecter l'aspect-ratio Portrait/Paysage/
Carré dans l'éditeur — ce réglage ne sert qu'à l'aperçu jouable/"Jouer",
voir screen_set_aspect.py) : "prendre toute la place disponible" et
"garder l'aspect-ratio" sont deux exigences contradictoires dès que la
fenêtre n'a pas exactement ce ratio, la première l'emporte ici. C'est
LUI qui défile (overflow:auto) si jamais le contenu déborde malgré
tout — jamais .builderCanvasArea (voir plus haut), pour garder la
barre d'onglets/d'outils toujours visible. */
flex:1 1 auto; min-height:0; width:100%; padding:4px; border:1px solid var(--border); border-radius:16px; background:var(--panel);
display:flex; overflow:auto;
}
.canvas{
/* "Doit prendre toute la place disponible" ET garder son aspect-ratio :
un pur CSS (aspect-ratio + height:100%/max-width:100%) laissait trop
souvent le canevas bien plus petit que l'espace réellement disponible
(le calcul "auto" d'un élément non remplacé dans ce contexte flex
n'est pas fiable) — fitCanvasToFrame() (screen_edit.html) calcule donc
lui-même, en JS, la plus grande taille en pixels qui tient à la fois en
largeur ET en hauteur dans .canvasFrame (comme un "object-fit:contain"),
posée directement en style inline. Cette règle ne sert donc que de
valeur de secours avant le premier calcul JS (et en repli < 1300px,
voir le media query plus bas qui la réactive). */
position:relative; width:100%; margin:0 auto; background:#0b0d12; border-radius:8px;
overflow:hidden; border:1px solid var(--border); flex:0 0 auto;
position:relative; width:100%; height:100%; flex:1 1 auto; margin:0; background:#0b0d12; border-radius:8px;
overflow:hidden; border:1px solid var(--border);
}
.canvasElement{
/* Pas d'overflow:hidden ici : une échelle (transform:scale) ou une