Drawable Texture

[GeorgeS2019]

godotengine/godot#105701

Godot 4.7

Could the libgodot of the latest Godot 4.7 through callback , return image of Drawable texture that one can display in e.g. WinForm or WPF

[thygrrr]

I wanna play with Godot 4.7 when I make the library ready for GodotCon Amsterdam, thanks a lot for the suggestion!

[GeorgeS2019]

godotengine/godot-proposals#14435 (comment)

[GeorgeS2019]

gdzig/gdzig#211 (comment)

[GeorgeS2019]

@thygrrr

April 24, 2026

[JimFFM2025]

@thygrrr
https://github.com/thygrrr/godot/tree/camera-stacking

Any success ? 😉

[JimFFM2025]

@thygrrr

April 24, 2026

https://youtu.be/LDSwP37y_W4?si=jHunRk4hStPEv7_r

Soon we will get the presentation above

[GeorgeS2019]

@srbd-windows

godotengine/godot-proposals#14848 (comment)

[GeorgeS2019]

https://youtu.be/aGxjJsABmx8?si=PLH3e3bR42_wC2g_
June 17, 2026

[GeorgeS2019]

Based on the technical concepts described in the GodotCon presentation and Microsoft's official Windows development documentation, here is a detailed elaboration of how this specific rendering surface subclass and the XAML component work together.

The Microsoft XAML Component: SwapChainPanel

When the presenter mentions that "Microsoft thought of that and there is actually a special component," he is referring to a specific Windows XAML control called the SwapChainPanel (used in UWP and modern WinUI 3 / Windows App SDK applications).
The SwapChainPanel is designed specifically for high-performance graphics interop. It allows developers to reserve a rectangular area within their standard XAML user interface (which might otherwise contain normal Windows buttons, text boxes, and menus) and dedicate that area entirely to native DirectX rendering.

How the RenderingNativeSurface Subclass Works

In LibGodot, the base RenderingNativeSurface is an abstraction layer that tells Godot where to draw its pixels. To embed Godot into a XAML application using DirectX 12, a highly specific subclass of RenderingNativeSurface is utilized.
Here is the step-by-step breakdown of how this subclass connects Godot to the SwapChainPanel:
1. Creating the Swap Chain
In graphics programming (DirectX/DXGI), a "swap chain" is essentially a collection of memory buffers. Godot's rendering engine constantly draws the next frame into a hidden "back buffer," and when it's done, it "swaps" it to the "front buffer" to be displayed on screen.
The custom RenderingNativeSurface subclass instructs Godot's DirectX 12 engine to render its output into a dedicated composition swap chain rather than a standalone Windows desktop window.
2. Bridging Godot and XAML
Once Godot has its DXGI swap chain set up, it needs to be handed over to the Windows UI.
Under the hood, the XAML SwapChainPanel implements a native COM interface called ISwapChainPanelNative. The LibGodot abstraction allows the host application to take the swap chain Godot is rendering into and pass it to the XAML panel using a method like SetSwapChain().
3. Seamless Compositing
Because Godot is rendering directly into its own independent swap chain, it runs at full GPU hardware acceleration without being bogged down by the surrounding UI framework. Meanwhile, the Windows Desktop Window Manager (DWM) takes Godot's swap chain and effortlessly composites (blends) it together with the rest of the host application's XAML UI tree.

Why this approach is powerful:

• True Embedding: Godot isn't just a floating window forced to sit on top of the application. Because it is part of the XAML visual tree, you can place native Windows UI elements (like a native pop-up menu or a translucent settings panel) over the Godot 3D view, and it will render perfectly.
• Input Handling: The SwapChainPanel can natively capture mouse, keyboard, and touch inputs from the Windows OS and pass them directly through LibGodot's APIs to control the Godot scene.

[GeorgeS2019]

@migeran
@zorbathut
@thygrrr
@the-argus

Below is from AI:

To understand how this works at the code level, we have to look at the intersection of Godot's display server architecture and Windows' DXGI (DirectX Graphics Infrastructure) APIs.
Since the exact implementation inside Migeran's proprietary/in-progress branches isn't entirely public yet, I will propose the architectural code structure based on how Godot handles the RenderingNativeSurface base class and how Microsoft's ISwapChainPanelNative API explicitly requires integration.
Here is a proposed breakdown of how the C++ code for this custom subclass instructs Godot's DirectX 12 engine.

1. Defining the Custom Surface Subclass

First, the host application needs a way to pass the XAML component to Godot. In LibGodot, this is done by extending the base RenderingNativeSurface class. For XAML, we propose a RenderingNativeSurfaceXAML subclass that holds a pointer to the native COM interface of the XAML control.

#include "core/os/rendering_native_surface.h"
#include <windows.ui.xaml.media.dxinterop.h> // For ISwapChainPanelNative

class RenderingNativeSurfaceXAML : public RenderingNativeSurface {
    GDCLASS(RenderingNativeSurfaceXAML, RenderingNativeSurface);

private:
    // A pointer to the XAML control's native interface
    ISwapChainPanelNative* swap_chain_panel = nullptr;

public:
    // Constructor accepts the COM interface from the host application
    RenderingNativeSurfaceXAML(ISwapChainPanelNative* p_panel) {
        swap_chain_panel = p_panel;
    }

    ISwapChainPanelNative* get_swap_chain_panel() const {
        return swap_chain_panel;
    }

    // Identifies the surface type to the Display Server
    virtual SurfaceType get_type() const override {
        return SURFACE_TYPE_WINDOWS_XAML;
    }
};

2. Instructing Godot's Display Server to Use Composition

Normally, when Godot creates a window on Windows, its DisplayServerWindows creates a standard OS window (HWND) and tells the DirectX 12 rendering device to build a swap chain for it using CreateSwapChainForHwnd.
With LibGodot, the Display Server checks the type of the RenderingNativeSurface provided. If it detects our XAML surface, it branches into a specialized initialization path.

// Inside Godot's DirectX 12 Context Initialization (e.g., in rendering_context_driver_d3d12.cpp)

HRESULT RenderingContextDriverD3D12::create_swap_chain(RenderingNativeSurface* p_surface) {
    DXGI_SWAP_CHAIN_DESC1 swap_chain_desc = {};
    swap_chain_desc.Format = DXGI_FORMAT_B8G8R8A8_UNORM; 
    swap_chain_desc.SampleDesc.Count = 1;
    swap_chain_desc.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT;
    swap_chain_desc.BufferCount = 2; // Double buffering
    
    // CRITICAL: Swap chains for XAML panels must use flip models
    swap_chain_desc.SwapEffect = DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL; 
    
    // CRITICAL: Must support composition with pre-multiplied alpha
    swap_chain_desc.AlphaMode = DXGI_ALPHA_MODE_PREMULTIPLIED;

    ComPtr<IDXGISwapChain1> swap_chain;

    if (p_surface->get_type() == SURFACE_TYPE_WINDOWS_XAML) {
        // 1. Cast the surface to our custom XAML subclass
        RenderingNativeSurfaceXAML* xaml_surface = static_cast<RenderingNativeSurfaceXAML*>(p_surface);
        
        // 2. Create a swap chain for COMPOSITION, not a standard HWND
        HRESULT hr = dxgi_factory->CreateSwapChainForComposition(
            command_queue.Get(), 
            &swap_chain_desc, 
            nullptr, 
            &swap_chain
        );

        if (SUCCEEDED(hr)) {
            // 3. Bind Godot's new composition swap chain directly to the Windows XAML UI element
            ISwapChainPanelNative* panel_native = xaml_surface->get_swap_chain_panel();
            hr = panel_native->SetSwapChain(swap_chain.Get());
        }
        return hr;
    } else {
        // Fallback: Standard desktop window creation (HWND)
        // dxgi_factory->CreateSwapChainForHwnd(...)
    }
}

3. Usage from the Host Application (C# / UWP / WinUI)

From the perspective of the application developer embedding Godot, the C++ code above is hidden. The developer simply passes their XAML SwapChainPanel to LibGodot during initialization.
Here is how that host integration code would look conceptually in C#:

using Godot;
using Microsoft.UI.Xaml.Controls;
using WinRT; // For COM interop

public void InitializeGodotEmbedded(SwapChainPanel myXamlPanel)
{
    // 1. Cast the managed XAML panel to its underlying native COM interface
    var panelNative = myXamlPanel.As<ISwapChainPanelNative>();

    // 2. Create the LibGodot native surface wrapper
    var nativeSurface = new RenderingNativeSurfaceXAML(panelNative);

    // 3. Initialize Godot, passing the custom surface instead of creating a new window
    var initConfig = new LibGodotInitConfig();
    initConfig.MainSurface = nativeSurface;
    initConfig.RenderMode = RenderMode.DirectX12;
    
    LibGodot.Initialize(initConfig);
    
    // Godot will now render directly into 'myXamlPanel'
}

Summary of the Mechanism

Instead of asking Windows for a physical window handle (HWND), the subclass intercepts the graphics setup. It forces the DX12 driver to use CreateSwapChainForComposition to generate a headless swap chain. It then links that headless swap chain directly to the UI framework via the SetSwapChain method provided by the host's ISwapChainPanelNative pointer. This allows Godot to render asynchronously on the GPU while Windows automatically layers it perfectly inside the application.

[GeorgeS2019]

the RenderingNativeSurface was designed as a reference-counted base class (inheriting from RefCounted). This approach eliminates manual memory management errors and allows these surfaces to be easily exposed and controlled via the GDExtension API from languages like C#, Swift, or Java.
Here is a conceptual breakdown of the code for the RenderingNativeSurface base class, followed by the specific structural additions required to make Windows UI embedding work.

1. The RenderingNativeSurface Base Class

The core responsibility of this class is to act as a factory that generates compatible RenderingContextDrivers based on the platform and rendering backend (Vulkan, OpenGL, or DirectX).

// core/os/rendering_native_surface.h
#include "core/object/ref_counted.h"

class RenderingContextDriver;

class RenderingNativeSurface : public RefCounted {
    GDCLASS(RenderingNativeSurface, RefCounted);

protected:
    static void _bind_methods(); // Exposes the class to GDExtension

public:
    // Factory Method: Creates the corresponding context driver for this surface
    virtual RenderingContextDriver* create_context_driver() const { 
        return nullptr; 
    }

    RenderingNativeSurface() {}
    virtual ~RenderingNativeSurface() {}
};

2. Additions Needed for Windows UI Embedding

To fully enable Windows UI embedding (whether using XAML SwapChains, Qt external textures, or standard HWNDs), the following specific additions must be integrated into the existing Godot/LibGodot codebase:

A. A Platform-Agnostic Embedded Display Server

Instead of hacking DisplayServerWindows with an endless web of conditional statements, Migeran's architecture introduces a unified DisplayServerEmbedded. This server is designed specifically to accept RenderingNativeSurface objects rather than requesting standard OS windows.

// platform/embedded/display_server_embedded.h
#include "servers/display_server.h"
#include "core/os/rendering_native_surface.h"

class DisplayServerEmbedded : public DisplayServer {
    // ... 
public:
    // During initialization, it takes the native surface provided by the host process
    DisplayServerEmbedded(const Ref<RenderingNativeSurface>& p_surface);
    
    // Bypasses the native Windows message pump, as the host app handles it
    virtual void process_events() override; 
};

B. Extending the Window Node Class

The host application needs a way to target specific viewports dynamically. The Godot Window class must be extended with new methods to accept a RenderingNativeSurface. This allows you to route Godot popups or sub-windows directly into native Windows UI components.

// scene/main/window.h
class Window : public Viewport {
    GDCLASS(Window, Viewport);

private:
    Ref<RenderingNativeSurface> native_surface;

public:
    // Sets the target surface safely and dynamically
    void set_native_surface(const Ref<RenderingNativeSurface> &p_surface);
    Ref<RenderingNativeSurface> get_native_surface() const;
};

C. Windows-Specific Surface Subclasses (External Textures)

If you are embedding Godot into a complex UI framework on Windows (like Qt via Vulkan) rather than just dropping it into an empty rectangle, you cannot just share a window handle. You must share textures.
As noted in Migeran's design rationale, you need to create specialized subclasses like RenderingNativeSurfaceVulkanExternalTextureWin32. This subclass contains a thread-safe queue to synchronize the Vulkan frames rendered by Godot with the frames consumed by the host application's UI thread.

// platform/windows/rendering_native_surface_vulkan_win32.h
#include "core/os/rendering_native_surface.h"
#include "core/os/mutex.h"
#include <vulkan/vulkan.h>

class RenderingNativeSurfaceVulkanExternalTextureWin32 : public RenderingNativeSurface {
    GDCLASS(RenderingNativeSurfaceVulkanExternalTextureWin32, RenderingNativeSurface);

private:
    // Thread-safe queue to pass finished Vulkan texture handles to the host UI
    Mutex queue_mutex;
    List<VkImage> ready_textures;

public:
    void push_ready_texture(VkImage p_image);
    VkImage pop_ready_texture(); // Called by the host process (e.g., Qt) to display

    virtual RenderingContextDriver* create_context_driver() const override;
};

Summary of the Flow

1. The host Windows application (written in C# or C++) creates a RenderingNativeSurface subclass (e.g., for XAML, HWND, or Vulkan textures).
2. It calls window.set_native_surface(my_surface) via the GDExtension bindings.
3. The newly added DisplayServerEmbedded detects this surface, calls the factory method create_context_driver(), and successfully bridges Godot's graphics output into the host UI without spawning an independent desktop window.

[raidenblackout]

https://github.com/raidenblackout/godot-winui3

You can check this Godot fork. It should be able to do what you are trying to do.

[GeorgeS2019]

@raidenblackout
Since it is using DirectX12, it should be possible to make it works for WPF, Avalon, and winform

Thank you.

[GeorgeS2019]

@hung-yueh

Check up
https://github.com/raidenblackout/godot-winui3