Understanding a Trace

Once a trace is captured and opened, use the views below to interpret OS scheduling and UI performance.

Processes

Upon loading the JSON file, several processes become visible. These processes always appear in the same stable order: Scheduler, UI, Animations, Tasks and Threads, and Traces. This deterministic ordering is preserved regardless of trace content.

The trace is organized into several processes, each expandable to reveal its tracks:

Scheduler: CPU time per process, split into Idle, OS Tasks, and VEE Threads.
UI: traces useful for debugging UI performance: frames, display back buffers, and image destinations.
Animations: the lifecycle of MWT animations.
Tasks and Threads: per-task and per-thread flame graphs of the application.
Traces: every event grouped by type rather than by task or thread.

Scheduler

Expanding the Scheduler process reveals three sub-items:

Idle: periods when the CPU is not in use.
OS Tasks: aggregates all events executed by OS tasks and interrupts into a single line. Tasks are prefixed [OS] <name>.
VEE Threads: threads from the Virtual Execution Environment (VEE) and the Garbage Collector (GC). Threads are prefixed [MEJ] <name>.

Scheduler process showing Idle, OS Tasks, and VEE Threads — The Scheduler process with its three sub-items.

UI

Note

The UI traces are more comprehensive with UI Pack 14.4.0 or higher (best with 14.5.2), VG Pack 1.8.0, and MWT 3.6.2. Older versions still work but produce fewer events.

This process aggregates traces useful for debugging UI performance. The tracks appear in a stable order: Frames, Display Back Buffers, Buffered Images, Buffered Vector Images, Unresolved Destinations.

Frames

The Frames track shows the time intervals between each display flush. Zooming in reveals the frame number and the instantaneous FPS.

A sub-block named Wait Free Back Buffer shows the wait time for the next back buffer, especially when it is in use by the screen driver. Its duration depends on the buffer policy.

Frames track showing frame intervals and FPS — The Frames track with frame numbers and instantaneous FPS.

Destination Tracks

The four destination tracks, ordered from the most general to the most specific, are:

Display Back Buffers: shows the scheduling of display back buffers (see buffer policy). A buffer block begins when the application starts drawing on it and ends at the display flush.
Buffered Images: groups drawings made in identified buffered images, matched by their UI_NewImage address.
Buffered Vector Images: groups drawings made in buffered vector images, identified via VG_NewImage.
Unresolved Destinations: groups drawing events whose target buffer could not be matched to any known destination. This can happen when the UI_Flush/UI_FlushDone pair is missing, the UI_NewImage or VG_NewImage event is missing, or the UI Pack is older than 14.5.2 / VG Pack older than 1.8.0. With recent pack versions, this track should contain very few events.

Note

When using the Perfetto format, each destination address is assigned a unique fixed color for easy visualization of buffer swapping and image reuse. This coloring is only available in Perfetto; Chromium DevTools does not support it (see Restrictions).

These tracks share a common structure: each groups drawing events by their target buffer (destination). Zooming in reveals sub-blocks for:

Software: all drawings made by the CPU.
GPU: all drawings made by the GPU (from native call to LLUI_DISPLAY_notifyAsynchronousDrawingEnd(), see GPU Port).

A single destination showing both Software and GPU drawing sub-blocks — A single display back buffer destination with both Software and GPU drawings.

All drawing times for a given destination are summed and displayed next to its address.

When an async GPU drawing is still in progress at a destination change (e.g., the application starts drawing on another buffer), the tool preserves the full GPU drawing time:

Cross-line split (display↔image): the destination span is extended to cover the full GPU duration. Since the two destinations are on separate lines, there is no overlap and the parallelism between CPU and GPU work remains visible.
Same-line split (e.g., two different images): the GPU drawer is split at the changeover point with semantic naming (GPU… for the part belonging to the original destination, …GPU for the continuation). The full GPU drawing time is preserved in the original destination’s drawing time; the …GPU continuation does not count in the next destination’s drawing time.

Animations

The Animations process shows the lifecycle of MWT animations. Each line (slot) represents one animation track. Slots are recycled when an animation ends. Each slice shows the animation’s TypeID, ObjectID, and frame rate (e.g., MotionAnimation$1 (ObjectID=24687; fps = 34Hz)).

Note

Requires MWT ≥ 3.6.2.

Animations process showing animation tracks with ID and frame rate — The Animations process.

Tasks and Threads

This view distinguishes each OS task (prefixed [OS]) and each VEE thread (prefixed [MEJ]) on separate lines. Only tasks and threads that have traces captured during the recording are displayed.

Expanding this section reveals the flame graphs of the application. For a UI application running under MWT, the VEE thread [MEJ] UIPump handles all UI operations.

Note

VEE threads all execute within the OS task “OS VEE”. The tool redistributes traces from the OS VEE task to the correct VEE thread line for clarity.

Tasks and Threads process with flame graphs per task and thread — Tasks and Threads expanded, showing flame graphs for each OS task and VEE thread.

Traces

This process displays all traces categorized by type rather than by task or thread. This organization allows a quick view of when a trace is recurring. Each line represents a different event type.

This process can be quite large and should typically remain collapsed, expanded only when searching for a specific trace.

The Traces process expanded showing event types on separate lines — The Traces process, with each event type on a separate line.

Trace Summary

Each trace is composed of a short name (visible in the graph when zooming in) and more detailed information. To display the details, select a trace and open the “Summary” view in the bottom panel. These details are the same as those observable in SystemView (based on the SYSVIEW_*.txt description files).

Summary panel showing trace details — The Summary panel displaying event details for a selected trace.