Performance comparison: native CAD viewer integration versus web-based viewers

PLM Oracle Agile PLM
, , , , , , ,
1

We’re evaluating whether to continue with Agile’s native CAD viewer integration or migrate to a modern web-based viewer solution. Our engineering team uses the viewer extensively for design reviews and markup collaboration.

I’m interested in hearing performance comparisons from teams who’ve used both approaches. Specifically: rendering speed for large assemblies, browser compatibility issues with web viewers, and how well each integrates with Agile’s change management workflows.

Our current native viewer works but feels dated, and we’re getting pressure to support remote workers who prefer browser-based access. However, I’m concerned about performance degradation with complex CAD files. What have others experienced?

2

Having implemented both solutions across multiple Agile installations, I can provide a comprehensive comparison across the three key dimensions.

Rendering Speed: Native viewers consistently outperform web-based solutions for rendering speed, particularly with large assemblies. The performance gap stems from architectural differences - native viewers leverage local GPU acceleration and can cache geometry data on the client machine, while web viewers must transmit rendered frames or geometry over the network and rely on browser graphics APIs.

Benchmarks from our testing:

  • Simple parts (50 components): Native 2-3s, Web 4-6s
  • Medium assemblies (200 components): Native 6-8s, Web 12-18s
  • Complex assemblies (500+ components): Native 15-20s, Web 30-45s
  • Very large assemblies (1000+ components): Native 25-35s, Web 60-90s or timeout

The rendering speed gap widens with file complexity, especially for assemblies with detailed surface textures, multiple layers, or extensive metadata. However, modern web viewers using WebGL and progressive loading techniques have narrowed this gap significantly compared to older implementations. Some premium web viewers now achieve near-native performance for typical engineering workflows.

Browser Compatibility: This is where web viewers face the most variability. Chrome and Edge Chromium provide the most consistent experience, with good WebGL support and predictable rendering behavior. Firefox works well but occasionally has font rendering issues with annotations. Safari on macOS is generally solid, but iOS Safari has limitations with large file handling.

Key compatibility challenges:

  • WebGL support varies by browser version and GPU drivers
  • Memory constraints in browsers limit maximum assembly size
  • Touch gesture support differs across mobile browsers
  • Some enterprise security policies disable WebGL, breaking viewer functionality
  • Browser extensions can interfere with viewer rendering

Recommendation: Establish a supported browser matrix and test thoroughly with your actual CAD formats. STEP, IGES, and JT formats generally have better cross-browser support than proprietary formats like CATIA or NX.

Workflow Integration: This is where the choice becomes strategic rather than purely technical. Native viewers typically offer deeper integration with Agile’s native functionality - markup tools, measurement capabilities, BOM navigation, and section views are often more feature-rich. Web viewers prioritize accessibility and collaboration but may sacrifice advanced features.

For workflow integration, consider:

  • Markup synchronization between viewer types
  • Integration with change management workflows (ECO creation from markups)
  • Support for design review meetings with real-time collaboration
  • Mobile access for field engineers and remote approvers
  • Integration with downstream systems (ERP, MES) that consume viewer data

Our recommendation for most organizations: Hybrid approach. Deploy web viewers as the default for broad accessibility and casual viewing, but maintain native viewer availability for power users and complex analysis tasks. Configure Agile to automatically suggest native viewer for files exceeding size/complexity thresholds. This gives you flexibility while optimizing user experience based on use case. Monitor usage analytics to refine the threshold over time based on actual user behavior and performance metrics.

3

Good point about markup sync. We rely heavily on redlines for design review workflows. Has anyone successfully maintained both viewers in parallel during a transition period? I’m wondering if a phased rollout makes sense, starting with simpler parts and assemblies in the web viewer while keeping native for complex models.

4

Phased rollout is definitely the way to go. We ran parallel viewers for six months, giving users a choice. Adoption metrics showed that 70% preferred web for simple reviews and quick checks, but switched back to native for detailed analysis and complex assemblies. The sweet spot was around 200-part assemblies - below that, web performance was acceptable; above that, native was noticeably faster. Document size matters too - files over 100MB struggled in browsers regardless of part count.

5

The workflow integration aspect is critical and often overlooked. Native viewers typically have tighter integration with Agile’s markup and redlining features. Web viewers may require additional API work to sync annotations back to Agile properly. We found that some web viewers store markups in their own database, creating synchronization challenges. You need to verify that markups created in the web viewer appear correctly for users still on native clients, and vice versa. This bidirectional compatibility isn’t always guaranteed out of the box.

6

We migrated from native to web-based last year and the rendering speed difference was noticeable. Large assemblies with 500+ parts that loaded in 8-10 seconds with the native viewer now take 15-20 seconds in the browser. However, the user experience improvements offset the performance hit for most users. The web viewer works on tablets and phones, which has been huge for field engineers doing reviews at customer sites.