WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable?

thejesh — Fri, 07 Aug 2026 17:49:53 -0000

Hi,

I urgently need some help from you to reach Codesys Support on priority

On CODESYS V3.5 SP22 Patch 2, WebVisu only (no TargetVisu). The client is Chromium 147 in kiosk mode on a Raspberry Pi CM5 panel; the runtime is CODESYS Control Win V3 x64/CODESYS Control RTE V3 x64 on a separate IPC.

I have measured that changing a Frame element's switch-frame variable destroys the currently referenced visualization and fully rebuilds it on return, including all embedded HTML5 controls. We would like to know whether this lifecycle is configurable.

Measurement 1:

Curently, our production page contains a good number of custom HTML5 controls and will only increase , each of which the WebVisu client instantiates as a separate about:srcdoc iframe. I counted live targets via the Chromium remote debugging endpoint (curl http://localhost:9222/json/list) before and after switching.

Production displayed (index 0) 108 iframes
Switched to a light page (index 1) 46 iframes
Switched back to Production 108 iframes

62 controls are destroyed on leaving the page and re-instantiated on return. Observed latency was approximately 2.5 -5s away from the heavy page and approximately 4.0 -5 s back to it.

This was measured with the panel otherwise idle: 2.8% system CPU, 97.1% idle, 2 h 56 min uptime, no remote-desktop session running, hardware acceleration confirmed active in chrome://gpu.

I had previously measured the same behaviour under a much higher CPU load and have since resolved that load separately (VISU_TASK cycle period), so I am confident the rebuild is the frame lifecycle itself and not CPU starvation.

Measurement 2 — frame offset instead of switch index

I then displayed the same overlay page by a different mechanism. Instead of using a switch-frame index, I placed the page in a fixed Frame parked off-screen below the visible canvas, and drive its Y offset from an INT in Structured Text to move it into view.

With this approach the overlay appears immediately, the production page underneath is never torn down and keeps updating, and no visualization is destroyed or rebuilt in either direction. The iframe count does not change at any point. This is the same visualization, containing the same HTML5 controls, as in Measurement 1 — the only difference is how it is brought on screen.

So the rebuild appears to be a property of the switch-frame mechanism specifically, not of the page or its control count.

Questions:

Is the destroy-and-rebuild behavior on switch-frame the intended and documented lifecycle for WebVisu?
Is there any setting, property or client option that causes a referenced visualization to remain instantiated when it is not the active index — the equivalent of keeping it mounted but not displayed?
Does the runtime or client offer any form of caching or pre-instantiation for referenced visualizations, so that a return switch does not pay the full construction cost?
Is the cost specific to HTML5 controls, or would the same rebuild occur with an equivalent number of native visualization elements? We ask because it would inform whether reducing our HTML5 control count is a viable solution.
Is there a recommended pattern for showing a full-screen page over a live production screen without tearing the production screen down?

My current workaround is to keep every page permanently instantiated and move it on and off screen by driving a frame offset variable, which avoids the rebuild entirely but means every page stays live and consumes client resources for the life of the session. This works, but I would prefer to use the supported mechanism if one exists.

Any help on this is greatly appreciated.

Thank you!

Recent posts to WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable?

WebVisu: switch-frame destroys and rebuilds referenced visualization - is retention configurable?