RenderSurface

Why RenderSurface exists

RenderSurface is not trying to imitate a native WPF control. It exists because a MonoGame-hosted UI framework needs a clean seam between two different kinds of work: UI composition on one side, custom game or simulation rendering on the other.

In other words, this control is the bridge between the "WPF-style" part of InkkSlinger and the "draw whatever you want with MonoGame" part of your application.

The team split it enables

Imagine two teams working on the same product.

The gameplay team owns the simulation, rendering rules, textures, sprite batching, cameras, maps, debug overlays, or whatever custom visual system the game needs. They do not want to learn XML authoring, binding syntax, or control templates just to get a live viewport onto the screen.

The UI team, on the other hand, wants to build screens declaratively. They want a layout tree, labels, buttons, side panels, score readouts, status messages, commands, and bindings. They want to control placement, spacing, styling, and interaction without having to rewrite the game renderer itself.

RenderSurface is the meeting point between those two concerns.

What the game team provides

A frame, a texture, or drawing logic. They stay in the MonoGame world and keep authoring rendering code the way game code normally works.

What the UI team provides

The surrounding screen: the layout, the buttons, the labels, the commands, the bindings, and the rest of the application shell around that rendered content.

<Grid>
  <StackPanel Grid.Row="0">
    <Label Text="{Binding ScoreText}" />
    <Label Text="{Binding StatusText}" />
  </StackPanel>

  <RenderSurface Grid.Row="1"
                 Width="560"
                 Height="392"
                 Stretch="Uniform" />

  <Button Grid.Row="2"
          Text="Restart"
          Command="{Binding RestartGameCommand}" />
</Grid>

This is the important mental model: the view can stay declarative while the rendered content inside the RenderSurface remains fully custom.