BlinkGTK Resize Behavior

Starting from v1.0.10 iter8, BlinkWebView automatically follows its parent
container's size. This document covers the behavior specification, migration
notes, and differences from previous versions.

1. Overview

BlinkWebView inherits directly from GtkWidget and uses the canonical GTK4
size_allocate vfunc to receive size change notifications. Internally, it
invokes RenderWidgetHostView::SetSize() to automatically update Chromium's
rendering resolution.

You do not need to manually call blink_web_view_set_canvas_size() in your
application code.

2. Specification

2.1 Auto-follow Triggers

The following events automatically update the size of Chromium's view (RenderWidgetHostView):

2.2 Coordinate System

• size_allocate(w, h, baseline) receives w, h in GTK4 logical (CSS)
  pixels
• Chromium accepts logical pixels; internally multiplies by
  device_scale_factor for physical pixels
• On HiDPI (gtk_scale_factor=2), logical 1280x800 → physical 2560x1600

2.3 Minimal Example

#include <blink_gtk/blink_gtk.h>
#include <gtk/gtk.h>

int main(int argc, char* argv[]) {
  blink_gtk_init(&argc, &argv);  /* GTK4 は引数なし */

  GtkWidget* window = gtk_window_new();
  gtk_window_set_default_size(GTK_WINDOW(window), 1280, 800);

  BlinkWebView* view = BLINK_WEB_VIEW(blink_web_view_new());
  gtk_window_set_child(GTK_WINDOW(window), GTK_WIDGET(view));

  gtk_window_present(GTK_WINDOW(window));
  blink_web_view_load_uri(view, "https://www.example.com");

  return blink_gtk_run_main_loop();
}

No extra code is needed for resize handling. BlinkWebView automatically
follows the parent container.

3. Differences from Previous Versions

3.1 v1.0.10 iter7 and Earlier (Issue #58)

Before iter8, BlinkWebView did not follow parent size and was stuck at the
Chromium default 800x600. On HiDPI systems, this 800x600 was treated as
device pixels, resulting in an effective display of roughly 400x300 CSS pixels
in the top-left quarter of the window.

Applications had to manually call blink_web_view_set_canvas_size(view, w, h)
to work around this. However, GTK4's size-allocate signal is deprecated and
overriding GtkWidgetClass::size_allocate_vfunc from C application code is
impractical.

3.2 v1.0.10 iter8 and Later

blink_gtk_api.cc now implements:

1. GtkWidgetClass::size_allocate vfunc override in the BlinkWebView class
   • Receives allocation notifications from the parent and internally calls
     SetCanvasSize()
2. measure vfunc natural size changed to 0x0
   • Combined with internally-set hexpand=TRUE / vexpand=TRUE, this causes
     the widget to fill the available parent area cleanly
3. notify::scale-factor handler
   • Re-notifies the current size on HiDPI scale changes

Details: Issue #58
Fix commit: bdb709c

4. Caveats

4.1 Minimum Size Reduced to 0

Because measure returns natural=0, the widget can collapse to 0x0 if the
parent container doesn't enforce a minimum size. In practice, use
gtk_window_set_default_size() or gtk_widget_set_size_request() to set a
floor size.

4.2 set_canvas_size() Still Available

For use cases that require manual size control (headless testing,
automated resize diagnostics), blink_web_view_set_canvas_size(view, w, h)
is still available. Manual invocations coexist with automatic updates via
size_allocate.

4.3 Redundant Same-Size Calls Are Suppressed

GTK may invoke size_allocate multiple times with the same dimensions during
a layout pass. An internal check suppresses redundant Chromium IPC calls, so
there is no performance penalty.

5. Regression Detection

BlinkGTK release builds are automatically verified by
release/scripts/check-resize-follow.sh:

bash release/scripts/check-resize-follow.sh --tarball blinkgtk-*.tar.gz

This confirms that a window resize from 1280x800 to 1600x1000 triggers both
the size_allocate vfunc and the Chromium view's bounds update. Failure to follow is a
release blocker.

Related

• Issue #58 (fix)
• GPU Modes
• External Integration

Last updated: 2026-04-20 (v1.0.10 iter8)
Author: BlinkGTK Project