Known issues

Platform support

  • Kanzi Monitor builds for Windows, Android, Linux X11 (linux_x11_glx_cpp11), and — since 1.6.1 — Linux Wayland (linux_wayland_aarch64) and QNX 7.1 (qnx710_screen_aarch64_cxx). Some platforms that Monitor 1.9.1 supports are still not yet available — OpenHarmony, INTEGRITY, linux_mali_fbdev, and linux_drm_gbm. Support for additional platforms is planned for a future Kanzi Monitor release.

Kanzi 3.6 feature limitations

  • The resource-enumeration commands overwatch.allresources, overwatch.resourceinfo, and overwatch.framebuffers are available, but on Kanzi 3.6 they operate on the loaded resources only — the Kanzi Engine cannot enumerate registered-but-unloaded resources — so overwatch.allresources returns the same set as overwatch.resources.

  • A resource index returned by the enumeration commands is a short-lived handle, not a durable identifier: the resource-manager state can change at any time, so an index can become out of range or shift to a different resource between commands. Fetch a listing and pass its indices to overwatch.resourceinfo promptly, within the same application state. This is inherent to the resource listing and is not Kanzi 3.6-specific — on newer Kanzi versions the underlying ResourceManager::getAllResources() view is documented to be likely invalid after any iteration of the main loop. It affects the Monitor Web UI resource panel and MCP tools equally.

  • Runtime-internal composition textures that are not registered resources — for example the off-screen texture created by a Viewport 2D with Force Composition, or an auto-generated composition target — do not appear in the resource listing on Kanzi 3.6, because getAllLoadedResources() enumerates only registered resources (the Kanzi 3.9.10+ getAllResources() view would include them). Such a texture can still be previewed when it is the composition target of a render pass — overwatch.renderpasspreview reaches it through RenderPass::getCompositionResult() — but it cannot be addressed directly by overwatch.texturepreview <index>.

  • The built-in perfinfo command — which in Monitor 1.9.0 is registered by the Command Processor service to report the main-loop last frame duration — is not available on Kanzi 3.6 for the same reason (no MainLoopScheduler). Use perfinfo2 (Performance service FPS / frame time) or appfpsinfo (application FPS and PerformanceInfo level) instead.

  • The engine-shutdown quit command from Monitor 1.9.0 (which calls MainLoopScheduler::quit()) is not available on Kanzi 3.6, which has no MainLoopScheduler. The application-quit command is provided instead, named appquit to match the 1.9.0 command set (it calls Application::quit()); this is also the command the quit_application MCP tool invokes.

  • Runtime frame-rate limiting (fpslimit) is not a Kanzi Monitor core command on Kanzi 3.6. Monitor 1.9.0’s fpslimit calls MainLoopScheduler::setFrameRateLimit(), which Kanzi 3.6 lacks; the only 3.6 runtime control is the engine’s FPSConstraints, held as a protected Application member reachable only from an application-derived class. The monitor_example application therefore provides fpslimit as an application-tier command (see KanziPerformanceToolsApplication::setFrameRateLimit() in kanziperformancetools_main.cpp); integrate the same way in your own application if you need it.

  • On Kanzi 3.6, the Android application framework is native C++ only — there is no droidfw Java API. Kanzi Monitor is a prebuilt per-ABI native .so that you link into the application during the native (NDK/CMake) build through an IMPORTED target.

  • The UI service handles touch input only on Kanzi 3.6. Key input is not available — the engine’s key-input handlers (KeyEvent / notifyKeyInput) were added in Kanzi 3.9 — so addBasicUIScreen registers a touch handler only.

  • overwatch.props reports a node’s locally-set property values by walking the node’s metaclass property types (including those inherited from base classes and those supplied by concept mixins, such as TextBlock3D.Text) and reporting those with hasLocalValue set — Kanzi 3.6 does not expose 3.9’s direct locally-set-storage iteration (beginPropertyStorage). Two differences vs 3.9 follow: a locally-set property that is not declared in any of the node’s metaclasses (a purely dynamic / attached property) is not enumerated, and binding-source information is not reported (the getBindingRuntime* APIs are Kanzi 3.9+). Values are reported for the common types (bool, int, float, string, color, vector); other types (SRT, matrix) are listed without a value. This affects the Monitor Web UI property panel (its binding indicators stay inactive on Kanzi 3.6) and the get_node_properties MCP tool equally.

  • The reported SuspendWhenIdle state (the idlesuspend command, the Web UI Performance-tab toggle, and the MCP get_idle_suspend tool) reflects the last value set through Monitor, not the Kanzi Engine’s live state — Kanzi 3.6 exposes only Application::setAllowIndefiniteSleep(bool) with no matching getter, so Monitor shadows the value it last wrote (starting from disabled). Setting the value is always correct: the Web UI toggle and set_idle_suspend write an absolute idlesuspend 0/idlesuspend 1, which updates the engine and the shadowed value together, so after any Monitor set the engine, the console, the Web UI toggle, and the MCP tool all agree and hold the value you selected. The reported value can drift out of sync only if the application itself changes idle-suspend by another path (including enabling it at startup); it does not self-correct, because there is no getter to reconcile against. The drift is display-only — the engine’s actual behavior is never wrong — and it is bounded: the next Monitor set re-synchronizes everything, and the worst case for a toggle issued while the display is stale is a no-op write (the engine was already at the selected value) that still re-synchronizes the display.

Windows build configuration

  • On Windows, the static-library (non-_DLL) build configurations disable Whole Program Optimization (/GL / LTCG). This is a deliberate divergence from the standard Kanzi 3.6 Visual Studio plugin template, which enables it for every configuration, and it was done to reduce the size of the prebuilt libraries: a static library has no link step, so the librarian archives every /GL object together with its whole-program intermediate representation, which inflated kzmonitor.lib to hundreds of megabytes (and the Windows package accordingly). With Whole Program Optimization off the static library is a fraction of that size (plain /O2 object code), matching the Kanzi Monitor 1.9.1 build. The _DLL configurations — the primary Windows distribution artifact — keep it enabled and are unaffected. The only effect is that cross-module whole-program inlining across the static-library boundary at the consuming application’s link is not performed; per-translation-unit /O2 optimization is retained.

General

  • Kanzi Monitor disables the local console of the Command Processor when running in Kanzi Studio Preview. You can use the remote console in Kanzi Studio Preview.

  • Kanzi can load plugins from dynamic libraries in an unpredictable order. If other plugins depend on Kanzi Monitor during their initialization, explicitly load Kanzi Monitor from the application during startup (add "kzmonitor" to moduleNames before the other plugins, or register it from application code). This lets the application make sure that the Kanzi Monitor plugin loads first.

  • When you enable the remote console, Kanzi Monitor attempts to open a remote console and bind to a socket port. This can fail if another application or another Kanzi Monitor instance already uses that port. To resolve this issue, choose a different port number, or avoid running another Kanzi Monitor instance with the remote console enabled at the same time.

  • When you enable the serial console, Kanzi Monitor attempts to open the configured serial port. This can fail if the port does not exist, another application uses it, or it requires elevated privileges. On Windows, virtual COM port drivers (such as com0com) can require test-signed driver mode.

See also

Release notes

Migration guides