Engine Aurora

Engine: Aurora

Aurora (Sucrose.Live.Aurora, assembly Sucrose.Live.Aurora.exe) is Sucrose's Application engine. It is not a renderer in the usual sense: instead of drawing pixels itself, it launches an external program or game and reparents that program's window behind the desktop icons, one instance per monitor. Aurora is the only engine allowed for the Application type, and it is the default for it. Window embedding is handled with Skylark.Wing.

Audience: developers and advanced users. For the user-facing guide, see Type-Application.

Contents

• At a glance
• Technology
• Supported wallpaper types
• Runtime requirements
• How it works
• Per-monitor embedding
• Audio
• Cleanup and lifecycle watchdog
• Hardware acceleration and Stay Awake
• Interactivity and data APIs
• Strengths and limitations
• See also

At a glance

Property	Value
Project	Sucrose.Live.Aurora
Assembly	Sucrose.Live.Aurora.exe
Underlying tech	External process embedding (launch real app/game per monitor, reparent window)
Embedding library	Skylark.Wing
Preprocessor symbols	ENGINE, LIVE_AURORA
Engine enum member	EngineType.AuroraLive
Allowed for type	Application (only)
Default for	Application
Native dependency	None beyond .NET + Skylark (the embedded app supplies its own)
Interactive	Input forwarded (references RawInput.Sharp); the embedded app runs live
Audio / system data	Volume only (no JS data injection)

Technology

Aurora uses process embedding rather than a graphics pipeline. It launches an external executable — the "Application" wallpaper — and reparents the launched window so it sits behind the desktop icons. The reparenting/monitor enumeration is done through Skylark.Wing (Skylark.Wing.Utility.Screene).

"Aurora" is a branded internal codename for this app-embedding engine; it is not a third-party rendering technology. This lets you run a game, application, or screensaver as a live wallpaper, with one copy running per monitor.

Supported wallpaper types

Type	Supported
Application	Yes
Gif	No
Url	No
Web	No
Video	No
YouTube	No

Aurora renders the Application type only. It explicitly rejects URLs: if IsUrl(Source) is true, it closes immediately (if IsUrl(Source) → Close). Per the engine enum, ApplicationEngineType allows Aurora only, so there is no alternate engine for application wallpapers.

Runtime requirements

Aurora itself has no extra native runtime beyond Sucrose's bundled .NET 10 runtime (Sucrose.Runtime) and Skylark — it is pure managed (WPF) plus Skylark. However, the embedded application brings its own requirements: the program you run as the wallpaper must be installed/runnable and supplies whatever runtime it needs. Aurora targets .NET 10.0-windows and builds for x86, x64, and ARM64.

See System-Requirements and Runtime-Dependencies.

How it works

Aurora follows the shared engine App.xaml.cs skeleton (exception handlers → Sucrose.Shared.Watchdog; single-instance mutex SMMRM.Live; Security.Apply(); Configure() reading SucroseInfo.json, verifying Info.AppVersion <= app version, resolving Source). The Application-specific flow lives in View/Application.xaml.cs:

1. Resolves the application path from Info.Source; stores AppProcessName (via AuroraSettingManager, SMMCA.AppProcessName).
2. Enumerates monitors with Skylark.Wing.Utility.Screene and launches one process instance per screen, passing Info.Arguments to each.
3. Waits via Ready.Check until all instances are ready, then reparents/embeds each window (Event/Application.cs → ApplicationEngine()), wiring ApplicationLoaded / ApplicationRendered.
4. On DisplaySettingsChanged, re-applies the embedding to all instances.
5. A GeneralTimer watches the spawned processes; if any child has exited or stopped responding, Aurora shuts down with Environment.Exit(0).

Like other engines, Aurora starts the shared Awakening.Start() (Stay Awake), Crashing.Start(), and Cycyling.Start() helpers, and keeps the Backgroundog flags (PipeRequired, AudioRequired, SignalRequired, PausePerformance, TransmissionRequired) off.

Per-monitor embedding

A key behavior: Aurora launches one process instance per screen. On a multi-monitor setup, the application is started once for each display, then each window is reparented onto its monitor. If display settings change at runtime (DisplaySettingsChanged), Aurora re-applies the layout to every instance. See Multi-Monitor for how Sucrose tracks displays and ScreenIndex.

Info.Arguments (command-line arguments for the embedded app, ≤250 characters as validated by the Create dialog) are passed to each launched instance — see Create-Step-By-Step and Create-Package-Format.

Audio

Audio for the embedded application is handled through the shared Volume helper (SSEHV.Start()) plus SetVolume. Aurora applies volume to the launched app; it does not inject audio-reactive data into the app's content (only the Web type does that).

Cleanup and lifecycle watchdog

• The GeneralTimer continuously watches the spawned processes; Aurora exits if a child has died or stopped working.
• On Closing / Closed, Aurora kills the spawned application processes (Processor.Kill) so no orphaned instances remain.

This is why switching away from an Application wallpaper (or stopping Sucrose) terminates the embedded program — the lifetime of the app is bound to Aurora.

Hardware acceleration and Stay Awake

• HardwareAcceleration: Not applicable at the Aurora level — the embedded application's own renderer (WPF/native) handles GPU usage. There are no Aurora-side GPU flags.
• Stay Awake: Applies via the shared Helper/Awakening.cs 30-second SetThreadExecutionState loop (ON → ES_CONTINUOUS | ES_SYSTEM_REQUIRED | ES_DISPLAY_REQUIRED; OFF → ES_CONTINUOUS).

Interactivity and data APIs

Unlike the pure-media engines, Aurora references RawInput.Sharp (as do the browser engines), so it participates in input forwarding — the embedded application is a live, running program. However, Aurora does not support the JavaScript audio-reactive or system-status APIs; those are exclusive to the Web type on a browser engine (Engine-WebView / Engine-CefSharp). Aurora apps receive volume only.

Strengths and limitations

Strengths

• Run any external program, game, or screensaver as a live wallpaper.
• Per-monitor: one instance launched and embedded per display.
• Adapts automatically to display changes.
• The embedded app is genuinely live and interactive.

Limitations

• Application type only; rejects URLs.
• The only engine for Application — no alternate engine to switch to.
• The app's resource usage is entirely its own; embedding a heavy game is heavy.
• No audio reactivity / system-data injection (volume only).
• Embedded instances are terminated when the wallpaper stops.

📷 Screenshot needed: An Application wallpaper running via Aurora across two monitors (e.g. a game or screensaver embedded behind the desktop icons).

See also

• Engines-Overview — how engines are selected and launched
• Type-Application — using application wallpapers
• Engine-Comparison — full engine matrix
• Multi-Monitor — per-display behavior and ScreenIndex
• Create-Package-Format — Source and Arguments fields
• Choosing-Engines — per-type engine selection