Page History

Unified display runtime enabling C# code execution in both desktop and browser environments.

Platform → UI Technology → Clients | WebAssembly | Symbols | Drawing | Responsive | Layouts

Portable Display Architecture

Portable displays enable a single display configuration to run across multiple client types. The display markup (XAML) and business logic (C#) remain consistent—only the runtime environment changes:

Technical Implementation

How WebAssembly Works

The compilation and execution process:

1. Compilation - C# code compiles to .NET assemblies
2. Translation - Assemblies convert to WebAssembly modules
3. Download - Browser fetches Wasm modules and .NET runtime
4. Execution - Code runs in browser's WebAssembly VM
5. Interop - JavaScript bridge handles browser API calls

Shared Code Example

// This C# code runs in both WPF and WebAssembly
public void UpdateValue(double value)
{
    if (value > AlarmLimit)
    {
        TriggerAlarm();
        LogEvent("Limit exceeded: " + value);
    }
    UpdateDisplay(value);
}

The same business logic executes in both environments. Platform-specific code is isolated in conditional compilation blocks when needed.

Performance Characteristics

Platform-Specific Capabilities

Desktop-Only Features

• Task switching prevention (Ctrl+Alt+Del blocking)
• Direct hardware access
• Local file system access
• Multi-monitor support
• Windows service integration

WebAssembly-Only Features

• Zero installation deployment
• Automatic updates on page refresh
• Cross-platform compatibility
• Browser security sandbox
• URL-based access

Shared Features

• Display rendering logic
• Data binding
• Animation and transitions
• Event handling
• Business rule execution

Deployment Considerations

Initial Download Size

WebAssembly applications require downloading the .NET runtime and application assemblies:

• Runtime - ~2-3 MB compressed
• Application - Varies by complexity
• Caching - Browser caches reduce subsequent loads

Browser Requirements

WebAssembly support in modern browsers:

• Chrome 57+ (March 2017)
• Firefox 52+ (March 2017)
• Safari 11+ (September 2017)
• Edge 79+ (January 2020)

When to Use Portable Displays

Development Workflow

Creating portable displays:

1. Design - Create display in FrameworX Designer
2. Code - Write business logic in C#
3. Test Desktop - Verify in WPF client
4. Test Web - Verify in browser
5. Deploy - Single configuration serves both

Platform Detection

// Conditional code when platform-specific behavior needed
#if WEBASSEMBLY
    // Browser-specific implementation
    await JSRuntime.InvokeVoidAsync("alert", message);
#else
    // Desktop-specific implementation  
    MessageBox.Show(message);
#endif

Limitations and Trade-offs

WebAssembly Constraints

• Single-threaded execution model
• Browser memory limits (~2GB typical)
• No direct hardware access
• Initial load time for runtime download
• JavaScript interop overhead for browser APIs

Desktop Constraints

• Platform-specific (Windows/Linux)
• Requires installation
• Manual update process
• Local deployment complexity

Architecture Benefits

The portable display architecture provides:

• Single codebase - Maintain one version of display logic
• Consistent behavior - Same calculations and rules everywhere
• Reduced testing - Logic tested once applies to all platforms
• Flexible deployment - Choose client type per use case
• Future compatibility - New platforms can reuse existing displays

In this section...