Page History

One liner.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#

The Portable Display Revolution

The fundamental challenge in industrial automation has always been the trade-off between powerful desktop clients and accessible web interfaces. WebAssembly changes this equation entirely.

Build Once, Run Everywhere

With FrameworX's WebAssembly implementation, a single display configuration can run:

• Natively on Windows using WPF for maximum control
• In any browser using WebAssembly with zero installation
• On mobile devices with responsive design
• Embedded in applications through API integration

The display markup (XAML) remains consistent - only the runtime changes.

Why This Matters for Industrial Applications

Desktop Requirements Remain Critical

For control room operations, native desktop clients provide irreplaceable capabilities:

• Task switching prevention (Ctrl+Alt+Del blocking)
• Full-screen lock for operator safety
• Direct hardware access for specialized peripherals
• Multi-threaded execution for complex visualizations
• Guaranteed resource allocation

See Desktop, Web & Mobile Clients for detailed client comparisons.

Web Accessibility is Essential

Modern operations demand web access for:

• Remote monitoring from any device
• Mobile rounds and inspections
• Management dashboards
• Cross-platform compatibility
• Zero-installation deployment

The Code Behind Challenge

Traditional approaches forced a choice:

• .NET/C# for desktop - Powerful but Windows-only
• JavaScript for web - Portable but limited

This meant maintaining two codebases, doubling development effort, and risking inconsistencies.

WebAssembly as the Bridge

WebAssembly enables the same C# code to execute in both environments:

csharp

// This exact code runs in both WPF and WebAssembly
public void UpdateTemperatureUpdateValue(double value)
{
    if (value > AlarmLimit)
    {
        TriggerAlarm();
        LogEvent($"TemperatureLimit exceeded: " {+ value}°C");
    }
    UpdateDisplay(value);
}

Technical Implementation

1. Compilation: C# code compiles to WebAssembly modules
2. Runtime: .NET runtime executes within the browser
3. Interop: Seamless communication with browser APIs
4. Performance: Near-native execution speed

Performance Benefits

WebAssembly delivers performance previously impossible in browsers:

• Millisecond updates for thousands of data points
• Complex calculations executed client-side
• Reduced server load through edge processing
• Smooth animations at 60 FPS
• Binary communication protocols

Traditional HTML5/JavaScript architectures struggle with:

• Real-time updates beyond hundreds of points
• Complex mathematical operations
• High-frequency data streams
• Large dataset manipulations

WebAssembly handles these scenarios natively.

Architecture Advantages

Unified Communication Stack

The entire data pipeline runs in compiled code:

• Protocol handling
• Data transformation
• Business logic
• UI updates
• Event processing

Only the final rendering uses browser APIs.

Code Reusability

Beyond displays, WebAssembly enables code sharing across:

• Desktop applications (WPF)
• Web browsers (WebAssembly)
• Mobile apps (MAUI/Blazor)
• Python scripts (via interop)
• Edge devices (IoT)

Deployment Scenarios

Control Room (Desktop Priority)

• Rich Client with WPF for maximum control
• Task switching blocked
• Multi-monitor support
• Local redundancy

Remote Access (Web Priority)

• WebAssembly for zero installation
• Works on any device
• Automatic updates
• Cloud-ready

Hybrid Operations

• Same displays in both modes
• Seamless transition between clients
• Consistent user experience
• Unified training

Implementation Considerations

When to Use Portable Displays

• Multi-platform requirements
• Mixed desktop/web users
• Rapid deployment needs
• Future-proofing investments

When to Specialize

• Platform-specific features required
• Legacy system constraints
• Extreme performance requirements
• Regulatory compliance needs

Technical Requirements

Browser Support

Modern browsers with WebAssembly support:

• Chrome 57+
• Firefox 52+
• Safari 11+
• Edge 79+

Development Environment

• .NET 8 SDK
• Visual Studio 2022 or VS Code
• FrameworX Designer

Conclusion

WebAssembly transforms the traditional desktop-vs-web dilemma into a unified solution. Industrial applications no longer sacrifice power for portability or accessibility for control. The same C# code, the same business logic, and the same displays run everywhere - from locked-down control rooms to mobile devices in the field.

This is not about replacing desktop applications or making everything web-based. It's about having the freedom to deploy the right client for each use case without multiplying development effort.

Related Topics:

The same business logic executes in both environments. Platform-specific code is isolated in conditional compilation blocks when needed.
Performance Characteristics
Aspect
Desktop (WPF)
WebAssembly
Startup Time
Fast (local resources)
Slower (download runtime)
Execution Speed
Native performance
~70% of native speed
Memory Usage
Direct OS management
Browser heap limits
Threading
Full multi-threading
Single-threaded
Data Points
10,000+ simultaneous
1,000s practical limit
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
Use Portable Displays
Use Platform-Specific
Standard monitoring screens
Hardware control interfaces
Dashboard visualizations
High-frequency data updates (>100Hz)
Report displays
Multi-threaded processing needs
Cross-platform requirements
OS-specific integrations
Remote access scenarios
Local peripheral access
Development Workflow
Creating portable displays:
Design - Create display in FrameworX Designer
Code - Write business logic in C#
Test Desktop - Verify in WPF client
Test Web - Verify in browser
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
[Technology Foundation]

In this section...