cairo_surface_set_device_scale(): backend inconsistency and double-scaling risk

Short answer

There is no introspection API that tells you whether a backend honors device scale — cairo_surface_get_device_scale() only returns the value you set, not what the backend does with it. The practical answer to all three open questions is the same: treat the cairo_t CTM as the single authoritative scaling factor, keep the surface device scale at 1.0, and use cairo_surface_get_type() only to drive diagnostics and tests. This works uniformly because the CTM is respected by every backend, while device scale is not.

Confirmed behavior vs. likely explanation

Confirmed (well-established Cairo behavior, valid for 1.18.0):

• cairo_surface_set_device_scale() maps logical coordinates to device pixels but never resizes the underlying buffer. You must allocate the image surface at width × scale by height × scale yourself.
• Image surfaces honor device scale fully. PDF, PostScript, SVG, and Xlib/XCB surfaces ignore it — they render at 1× regardless.
• Win32, Quartz, and DRM may honor it depending on OS-level DPI configuration, so behavior is platform-dependent rather than API-guaranteed.

Likely explanation for your inconsistency: you are mixing two scaling mechanisms. When a GTK-managed cairo_t already carries a scale via its CTM (GTK applies the widget scale factor internally), adding a surface device scale multiplies them — effective scale = CTM × device scale — which produces the blurring or oversized output you describe.

Recommended pattern

1. Never call cairo_surface_set_device_scale() on a surface you draw to through a GTK-provided context. GTK has already scaled the CTM; adding surface scale is the double-scaling bug.
2. For your own image surfaces, pick one mechanism: either allocate the buffer at physical pixels and set device scale, or allocate at physical pixels and call cairo_scale(cr, s, s). Prefer the context approach — it survives a backend swap (e.g., offscreen image reused as PDF fallback) without code changes.
3. For PDF/PS/SVG export, scaling in the CTM is mandatory. These vector backends will not rasterize at higher resolution for you.

Runtime detection

Since no capability query exists, classify by surface type and assume the conservative case:

switch (cairo_surface_get_type(surface)) {
case CAIRO_SURFACE_TYPE_IMAGE:
    /* device scale honored */
    break;
case CAIRO_SURFACE_TYPE_PDF:
case CAIRO_SURFACE_TYPE_PS:
case CAIRO_SURFACE_TYPE_SVG:
case CAIRO_SURFACE_TYPE_XLIB:
case CAIRO_SURFACE_TYPE_XCB:
    /* device scale ignored: scale via cairo_scale() instead */
    break;
default:
    /* platform-dependent: verify empirically */
    break;
}

Verification

Write one minimal test per backend: draw a 100×100 logical rectangle with device scale 2.0 and no context scale, then measure output. Image surface should yield 200×200 device pixels; PDF/PS/SVG output will be 100×100. Also confirm your runtime version with cairo_version() against CAIRO_VERSION_ENCODE(1,18,0), and in GTK compare gtk_widget_get_scale_factor() with the context CTM at draw time.

One caution: cairo_push_group() creates an intermediate image surface that inherits the parent's device scale, so nested groups can compound scales silently — another reason to keep device scale at 1.0 everywhere.