I've tackled exactly this problem when porting FLTK custom widgets to Wayland, and the key is to stop directly using XLib-specific Cairo surface creation and leverage FLTK 1.4's built-in cross-platform Cairo integration instead. Here's a step-by-step breakdown of the best approaches:

1. Optimal Solution: Use FLTK's Native Cairo Context #

FLTK 1.4 abstracts away X11/Wayland differences in Cairo handling via helper functions. Instead of manually creating a Cairo surface with XLib, grab the pre-configured context that FLTK manages for the current widget/window:

void MyCustomDial::draw() {
    // Optional: Draw the base Fl_Dial first if you want to keep its default styling
    Fl_Dial::draw();

    // Get the cross-platform Cairo context from FLTK
    cairo_t* cr = fl_cairo_context();
    if (!cr) {
        // Fallback to FLTK's native drawing if Cairo isn't available
        return;
    }

    // Save the context state to avoid messing up FLTK's subsequent drawing
    cairo_save(cr);

    // Translate coordinates to the widget's local origin (FLTK uses widget-relative coords)
    cairo_translate(cr, this->x(), this->y());

    // Your custom Cairo drawing logic here (rotation, arcs, etc.)
    // Example: Draw a custom knob indicator
    cairo_set_source_rgb(cr, 0.2, 0.6, 0.8);
    cairo_arc(cr, this->w()/2, this->h()/2, this->w()/3, 0, M_PI/2);
    cairo_stroke(cr);

    // Restore the context state
    cairo_restore(cr);
}

This works seamlessly on both X11 and Wayland:

• On X11, FLTK provides the XLib-backed Cairo surface you previously used manually.
• On Wayland, FLTK automatically uses an EGL-backed Cairo surface tied to the Wayland window buffer, avoiding the segfault from direct XLib calls.

2. If You Need a Custom Surface (Rare Cases) #

If your widget requires an offscreen surface for intermediate rendering, use FLTK's fl_cairo_surface() helper instead of creating one from scratch. This function returns a surface compatible with the current display backend:

cairo_surface_t* surface = fl_cairo_surface(this->w() * fl_scale(), this->h() * fl_scale());
cairo_t* cr = cairo_create(surface);
// ... draw to cr ...
cairo_destroy(cr);
cairo_surface_destroy(surface);

FLTK handles scaling for HiDPI displays automatically via fl_scale(), so you don't need to hardcode scale values like before.

Key FLTK Source Code to Explore #

To understand how FLTK abstracts Cairo across backends, look at these files in the FLTK source tree:

• src/cairo/Fl_Cairo.cxx: Implements the cross-platform fl_cairo_context() and fl_cairo_surface() functions. You'll see how it dispatches to backend-specific logic.
• src/wayland/Fl_Wayland_Window.cxx: Check the cairo_surface() method to see how Wayland uses EGL to create Cairo surfaces.
• src/x11/Fl_X11_Window.cxx: Compare with the X11 backend's Cairo surface handling to spot the unified abstraction.
• test/cairo_test.cxx: FLTK's official Cairo demo shows how to use these helpers in practice.

Why Offscreen Bitmap Drawing Is a Last Resort #

While drawing to an offscreen Cairo surface and blitting it to FLTK works, it adds unnecessary overhead (bitmap allocation, copy operations) and defeats the purpose of using Cairo's direct rendering to the window buffer. Stick to the native FLTK Cairo context whenever possible.

内容的提问来源于stack exchange，提问作者Ichthyo