gtk: With SSD, window is drawn with default size before being redrawn with configured window-width/height

[gtjoseph]

If you're using client-side decoration or no decoration, the initial window draws using the configured width and height. If you're using server-side-decoration however, the initial window draws with the default size then resizes to the configured size. It's kind of annoying. The GLFW build does the same thing but of course window decoration doesn't matter in that case.

I thought that moving the "initial-size" stuff earlier in the initialization process would be a way to fix this but doing so would be fairly intrusive give all the moving parts, especially with GTK. Then I thought changing the default initial size to something tiny that couldn't be seen, then setting initial-size to the default if window-width/height weren't specified might work. Nope. Finally I thought I might be able to start the window minimized then restore it after all the resizes were done. That kinda worked.

For GLFW, it was simple. In apprt.glfw.init.Surface.init(), I just added an iconify() right after glfw.Window.create() and a corresponding restore() at the end of init(). Works great.

For GTK, starting the window minimized was easy... At the end of apprt.gtk.Window.init(), I added a call to gtk_window_minimize() right before the final call to c.gtk_widget_show(). Unfortunately, every place I tried to insert the corresponding call to gtk_window_unminimize() was too early and resulted in the window still drawing with the default size before resizing. The closest I got was adding it to apprt.gtk.Surface.setTitle() but that only kinda-worked and only if you weren't setting a static title because that gets set early. setTitle() also gets called often so it wasn't the best place anyway.

I suppose the "right" way to do this would be to do the calculations early and pass them in to the rt_app/rt_surface/window init steps. The rt_surface has to provide content scale anyway and the rest of the inputs to the calculations come from the font.

Any other ideas?

[jcollie]

What environment are you running in? My test VM with Wayland and KDE Plasma 6 doesn't show this behavior, but then it could be because it's rather slow compared to running on bare metal.

[gtjoseph]

Ah yeah, forgot to mention... Fedora 41 XFCE X11 bare metal, Core i7-6950X Decacore @ 3.00GHz w/ 64Gb memory.

I would have thought a slow environment would make the behavior more noticeable but maybe it's also a X11 vs wayland thing. BTW, I also tested both before and after your recent commits and got the same results so I don't think any recent changes are involved.

[jcollie]

I tried in the NixOS VMs that can be run from Ghostty (nix run .#x11-xfce if you have nix installed) and didn't see it there either. I had to manually set window-decoration=server but it seemed to be fine. TBF I was also running a debug version... Perhaps you can capture a video that shows the behavior?

[gtjoseph]

ghostty (main ✔) ᐅ git describe
v1.1.2-162-g3f715c29
ghostty (main ✔) ᐅ git log -1 --oneline
3f715c29 gtk: update menus to use popovers and builder ui files (#5781)

./tmp/config:

window-width=80
window-height=13
window-decoration = server

zig build -Demit-terminfo -Demit-termcap -freference-trace
./zig-out/bin/ghostty --config-default-files=false --config-file=./tmp/config

Set the playback speed to 0.25 and you can see it clearly.

2025-02-23_16-33-39.mp4