Browser & GPU Setup

Overview

realvirtual WEB renders on your device, not on a server. Everything you see — geometry, shadows, moving parts — is drawn by the graphics processor of the machine in front of you, through the browser.

That makes one question decisive for how the viewer feels: which GPU is the browser actually using, and is it using it at all? A modern workstation can end up rendering a machine model on the CPU, at two frames per second, without saying a word about it. This page shows how to check that in a minute, and how to fix it.

The single most common cause of “realvirtual WEB is slow” is not the model. It is a browser that has been handed the integrated graphics chip instead of the dedicated card, or one that has fallen back to software rendering entirely.

Supported browsers

Browser	Status	Notes
Google Chrome (current)	Recommended	Best-tested combination, full diagnostics, WebGPU available
Microsoft Edge (current)	Recommended	Same engine as Chrome; the usual choice on Windows panel PCs
Mozilla Firefox (current)	Supported	Works fully; reports the GPU name only in a generic form, so the viewer’s GPU diagnosis stays vague
Apple Safari (current, macOS/iPadOS)	Supported	Hardware acceleration is always on; no user setting to get wrong
Mobile Chrome / Safari (tablets, phones)	Supported	Automatically uses the reduced quality preset — see Tablets and panel PCs
Internet Explorer, legacy Edge	Not supported	No WebGL 2

The technical requirement is WebGL 2 with hardware acceleration, plus JavaScript. Every browser in the table above has had that for years — the risk is not the browser version, it is the configuration around it.

Keep the browser reasonably current. Graphics-driver bugs are worked around in the browser’s own graphics layer, so an old browser on a new driver (or the reverse) is a recipe for artefacts nobody else can reproduce.

Recommended hardware

	Runs	Comfortable
GPU	Any GPU with hardware-accelerated WebGL 2 — including Intel Iris Xe / UHD and AMD integrated graphics	A dedicated GPU: NVIDIA GTX/RTX, AMD Radeon RX/Pro, Intel Arc, or Apple Silicon
Video memory	Shared memory on an integrated chip	4 GB or more for large plant models
Display	Any	Note that a 4K screen asks the GPU for four times the pixels of a 1080p screen
CPU rendering	—	Not viable. See Remote desktops and virtual machines

Apple Silicon (M-series) is an integrated GPU by construction but performs in the class of a dedicated card; the viewer treats it as such and never warns about it.

How the viewer tells you

You do not have to guess. realvirtual WEB inspects the active GPU at startup and reports what it found.

If something is wrong, a banner appears at the top of the screen:

Orange — “Browser is using integrated graphics.” The viewer is running, but on the weaker of two available GPUs. The banner names the better card when the browser reveals it. You can dismiss it; it returns in a new session.
Red — “Hardware acceleration is disabled — rendering on the CPU.” The page is being drawn by the processor. This banner cannot be dismissed, because no amount of quality tuning will rescue a model in this state.

Nothing appears when the GPU is fine. The banner is suppressed on phones and tablets, where the advice would be meaningless.

Settings → Dev Tools → GPU

The full picture lives in Settings → Dev Tools, in the GPU section:

Row	What it means
Active	Vendor and model of the GPU currently drawing the scene
Architecture	GPU architecture, when the browser reports one
High-perf / Low-power	Other graphics adapters the browser exposes — the proof that a second, faster GPU exists and is not being used

A coloured pill next to the section header classifies the result: Discrete and Apple Silicon in green, Integrated in orange, Software (CPU) in red. When the browser hides the GPU name — Firefox does this by default — no pill is shown at all. That is not a fault; there is simply nothing to classify.

The benchmark

Below it, Run Benchmark (120 frames) renders the current scene as fast as the GPU allows and reports:

Uncapped FPS — frames per second without the display’s refresh limit
Avg Frame — milliseconds per frame
Headroom — that speed as a percentage of 60 fps

Above 200 % there is plenty of room. Between 120 % and 200 % the scene is close to what this device can carry. Below 120 % you are at the limit, and either the hardware or the model has to give.

Quote these numbers, together with the Active GPU line and the version at the bottom of the settings panel, in any performance support request. They answer most of the questions we would otherwise have to ask.

Windows: making the browser use the right GPU

On a laptop or workstation with two GPUs, Windows decides which one each application gets — and the default, “Let Windows decide”, frequently hands browsers the power-saving chip. This is the single fix with the largest effect.

Windows Settings → System → Display → Graphics.
Find your browser in the list. If it is not there, choose Add desktop app and select the browser’s .exe.
Open Options and set High performance.
Close the browser completely — every window — and start it again. The setting only applies to a fresh process.

On NVIDIA systems the same can be set in the NVIDIA Control Panel → Manage 3D settings → Program Settings: add the browser and select High-performance NVIDIA processor. Setting it in both places does no harm.

Two more Windows details worth checking on a laptop:

Power mode. Under Settings → System → Power & battery, “Best power efficiency” and Battery Saver both push work onto the integrated GPU and throttle clocks. Use Balanced or Best performance while working with a twin — and note that many laptops behave differently on battery than on mains power.
Hardware-accelerated GPU scheduling (same Graphics page) can help on modern drivers. It is safe to try; if anything looks worse, switch it back.

Check that hardware acceleration is on at all

In Chrome: Settings → System → Use graphics acceleration when available. In Edge: Settings → System and performance → Use graphics acceleration when available. In Firefox: Settings → General → Performance — clear “Use recommended performance settings”, then tick “Use hardware acceleration when available”.

Restart the browser after changing it.

Verify it with the browser’s own report

Open chrome://gpu (or edge://gpu; in Firefox, about:support → Graphics). At the top, under Graphics Feature Status, the lines that matter are:

WebGL:  Hardware accelerated
WebGL2: Hardware accelerated

Anything else — “Software only”, “Disabled” — explains the red banner directly. Further down, Driver Information names the exact GPU and driver version the browser has bound to. That string is what realvirtual WEB shows as Active.

If a feature is listed as blocklisted, the usual cause is an outdated graphics driver. Install the current driver from the GPU vendor (NVIDIA, AMD, Intel) rather than relying on Windows Update, which often carries much older versions.

Remote desktops and virtual machines

This is where the red banner usually comes from, and it deserves stating plainly: a Windows session without a GPU renders 3D on the CPU.

Typical culprits are Remote Desktop, Citrix, VMware Horizon and other VDI setups, virtual machines without graphics passthrough, and Windows Server installations. The GPU name in that case reads Microsoft Basic Render Driver, SwiftShader, or llvmpipe — all of which the viewer classifies as Software (CPU).

What helps, in order of preference:

Run the browser where the GPU is. On a service laptop or the machine PC itself, with realvirtual CONNECT serving the viewer locally. This is by far the simplest answer and needs no infrastructure.
Give the virtual machine a real GPU — GPU passthrough, GPU partitioning (GPU-P), or a vGPU profile. Once the guest has a working driver, the browser behaves like any other desktop.
On a Remote Desktop Session Host, install the vendor’s GPU driver and enable the policy Use hardware graphics adapters for all Remote Desktop Services sessions (Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment).
Citrix HDX 3D Pro or the equivalent from your VDI vendor, where one is licensed.

If none of these is possible, treat the twin as a document rather than a live view: the model still opens and can still be inspected, but interactive simulation on a CPU renderer is not a usable working mode.

macOS and Linux

macOS needs no configuration. Hardware acceleration is always on and Safari and Chrome both use the system GPU; on Intel Macs with two GPUs, macOS switches automatically and the “Automatic graphics switching” option in Battery settings governs it.

Linux is well supported with current Mesa or proprietary drivers, but Chrome does occasionally blocklist an older driver and fall back to software. chrome://gpu names the reason. Updating Mesa or the vendor driver resolves nearly all of these; forcing the blocklist off is a last resort and tends to trade a performance problem for a stability one.

Tablets and panel PCs

The viewer detects touch devices and adapts before the first frame: it starts on the Fast visual preset, disables antialiasing and stays on the WebGL backend. That is deliberate — a mobile GPU with a full-quality preset produces a slideshow.

A few things specific to shop-floor hardware:

Panel PCs often carry a low-power integrated GPU. Expect to work from the Fast preset, and reach for UI zoom (Settings → Visual → Display, 125 % or 150 %) rather than the operating system’s scaling to keep the overlay legible at arm’s length.
Mobile GPUs drop the rendering context under memory pressure or when the tab sits in the background for a long time. The viewer catches this and offers a reload instead of leaving a blank canvas. If it happens repeatedly, the model is too large for the device.
Kiosk mode does not change any of the above. The GPU rules are the same whether or not the browser has a title bar.

Automatic quality on first start

The very first time realvirtual WEB runs on a device, and only then, it picks a visual preset for you:

Phones, tablets and devices with an integrated or software GPU start on Fast — unlit rendering, no shadows, no antialiasing, a lower render resolution — and a one-time dialog tells you it happened.
Everything else starts on Default.

After that the choice is yours and the viewer never overrides it again. There is no watchdog quietly lowering quality while you work. Change the preset any time in Settings → Visual → Visual Presets, and if the frame rate is short, work down in this order: shadow quality, shadow map size, resolution, antialiasing, reflections. Each step gives back noticeably more than the one before it costs in appearance.

WebGL and WebGPU

The viewer ships on WebGL, and that is the right choice for production.

Settings → Visual → Renderer → Backend also offers WebGPU (experimental) on desktop browsers that support it. WebGPU is the newer graphics standard and can be faster on complex scenes, but it is not yet the supported path: some features fall back or are unavailable on it, and it is greyed out entirely on devices without a WebGPU adapter and on touch devices. Treat it as something to evaluate, not something to deliver on.

The choice is stored in your browser and switching it reloads the viewer. If a WebGPU experiment leaves the viewer in a state where you cannot reach the settings, append ?renderer=webgl to the URL — that forces the classic backend and takes precedence over the stored value.

Next to it, Static mesh batching collapses static geometry into a few large draw calls and is a substantial performance win. Switch it off only to test whether it is behind a rendering problem, then switch it back.

Troubleshooting

Symptom	Likely cause	Fix
Red banner, everything crawls	Software rendering — no GPU or acceleration off	Enable hardware acceleration; on RDP/VDI see above
Orange banner, sluggish on a good laptop	Browser bound to the integrated GPU	Windows Graphics settings → High performance, then restart the browser fully
Fast on one PC, slow on an identical one	Different power mode, or one is on battery	Set the power mode to Balanced or better, check the mains connection
Was fine, now slow after an update	Graphics driver regression or blocklist	Check `chrome://gpu`, install the current vendor driver
Black or blank 3D area	Rendering context lost, or a driver fault	Reload the page; if it repeats, update the driver and reduce the preset
Flickering, missing or wrongly drawn parts	Driver bug	Update the driver; test with Static mesh batching off to narrow it down
Slow only with several twins open	Each tab holds its own 3D context	Keep one viewer tab open at a time
No GPU pill in Dev Tools	Firefox hides the GPU name by default	Expected; read the GPU from `about:support` instead
Model loads, then the tab reloads or dies	Out of memory for the model on this device	Use a device with more video memory, or a reduced model