linux: render at the fractional output scale instead of the integer scale factor

[Reliacrt]

Summary

The Linux GTK host derives the canvas render scale from gtk_widget_get_scale_factor, which rounds to the integer wl_output scale. On a fractionally-scaled Wayland output the compositor's real scale differs from that integer:

• niri at scale 1.5 (and KWin fractional scaling) report wl_output::scale = 2 (the protocol only carries integers) but deliver the true 1.5 via wp_fractional_scale_manager_v1.
• The canvas renders at 2x (640x1040 for a 320x520 logical surface) and the compositor resamples the buffer down to 1.5x on presentation.

That buffer/compositor mismatch softens and jags every curve — glyph arcs, rounded button corners, chart lines — regardless of the renderer's own AA quality.

Fix

Use GDK's fractional-scale API (gdk_surface_get_scale, GDK >= 4.12) wherever the host previously read the integer gtk_widget_get_scale_factor / gdk_surface_get_scale_factor:

• new native_sdk_gtk_fractional_scale() helper (falls back to the integer factor on pre-4.12 GTK)
• scale-change callback, frame emission, and the drawing-area resize path
• the draw-time device-scale comparison, so the buffer stays 1:1 with the widget and the NEAREST fast path still holds
• window frame/resize event payloads
• a one-shot notify::scale connection on the surface so fractional scale changes (window moved to an output with a different 150%-style scale) re-sync geometry

Verification

Environment: Linux + niri, output scale 1.5, 2560x1600.

• Present-path instrumentation showed the fix in action: buf=480x780 logical=320x520 widget_scale=1.5 dev_scale=1.5 filter=NEAREST (previously 640x1040 / 2.0 / resampled).
• Automation snapshot reports gpu_scale=1.5 after the fix (was 2).
• Rounded corners and glyph arcs render smooth on-screen after the change; before it they showed visible stair-stepping on the same hardware and compositor.
• zig build validate passes; zig build test passes in the local gate run (a known flaky --listen-runner failure on this machine also reproduces standalone-clean and does not compile gtk_host.c; desktop-platform-tests, which does, passes standalone with this change).

Notes

• The examples/calculator window-height issue seen alongside this (hardcoded window_height = 490 in src/main.zig clips the last keypad row under a Linux titlebar) is a separate example bug; happy to file it separately if wanted.

[vercel]

@Reliacrt is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[Reliacrt]

Fixed both review findings in d5a56ca:

1. Use-after-free (notify::scale handler): the handler id is now stored in view->gpu_scale_notify_id and explicitly disconnected in native_sdk_teardown_gpu_surface_view before the view memory is freed. The surface belongs to the window and outlives the view, so this removes the dangling-handler window.

2. GTK 4.10 compilation: gdk_surface_get_scale() is now gated behind #if GDK_VERSION_MAX_ALLOWED >= GDK_VERSION_4_12 (GDK's version mechanism; GDK_CHECK_VERSION is not defined in the GDK headers), so builds on the supported GTK 4.10 fall back to gtk_widget_get_scale_factor — behavior on 4.10 is unchanged from before this patch. Also fixed GtkWidget *root = gtk_widget_get_root(...) to GTK_WIDGET(...) since the API returns GtkRoot *.

Verified: rebuilt the example against the patched SDK (ReleaseFast) — compiles clean and renders (gpu_scale=1.5 at runtime).

[Reliacrt]

Addressed the remaining GTK 4.10 build concern in cad2d3b: the three emit-path call sites (window frame, resize, and the window-state scale) now route through a new native_sdk_gtk_surface_scale() helper that guards gdk_surface_get_scale() behind #if GDK_VERSION_MAX_ALLOWED >= GDK_VERSION_4_12 and falls back to gdk_surface_get_scale_factor() on older GDK. Rebuilt against the patched SDK (ReleaseFast): compiles clean, renders at gpu_scale=1.5.