Skip to content

Canvas Performance

Jump to bottom
Bobby Comet edited this page Aug 2, 2026 · 1 revision

Canvas performance: draw rate vs sensor refresh

The Canvas node (canvas.root) is the always-present settings node at the top of the graph. Its Performance group has two controls that look similar but do different jobs:

Property Default What it controls
Draw rate (FPS) 30 How often Cairo redraws the HUD
Sensor refresh (Hz) 2.0 How often data sources are re-read

They are independent on purpose. Animations can stay smooth without hammering sensors, scripts, or the disk.

These fields map 1:1 onto CanvasSettings in the project model and are written into the generated conky.conf /Lua pipeline by codegen; the Canvas node itself does not draw anything.

Why two knobs?

A Conky HUD does two kinds of work every second:

  1. Draw — run the Lua draw hook, paint gauges, text, glow, graphs, etc.
  2. Sample — re-read CPU, RAM, network, temperature caches, weather, custom scripts, and so on.

If those were locked together, a 30 FPS neon pulse would also mean “poll sensors 30 times per second.” That is wasteful:

  • CPU % and RAM barely change between frames
  • Temperature and weather change even slower
  • Daemon scripts and ${execi} already have their own intervals
  • Extra reads cost CPU and can amplify noisy sensors

So Studio separates:

  • FPS → visual smoothness (glow, spiral, pulse, radar, orbit, equalizer motion)
  • Sensor refresh (Hz) → how often the values behind those visuals update

You can redraw a glow’s phase 30×/sec while only re-reading CPU temp twice per second.

Draw rate (FPS)

UI label: Draw rate (FPS)
Range: 1–144 (default 30)
Maps to: Conky’s update/draw cadence for the Lua hook (theme-specific update_interval /related settings in generated config).

What it affects

  • How smooth animated visuals look (Glow/Pulse, Spiral, Radar Sweep, Orbit Field, Equalizer Bars, needle motion if you animate it, etc.)
  • How often the full Cairo path runs (CPU cost of drawing)
  • Perceived lag when you move widgets in Live Preview (preview rebuilds are separate; FPS is about the running Conky window)

Guidance

Situation Typical FPS
Static text, bars, rings only 5–15
Light motion (soft pulse, slow spiral) 15–30
Heavy chrome (radar + orbits + multi graphs) 30–60
“Butter” at high cost 60–144

Higher FPS always costs more CPU on the draw path. It does not by itself make sensors more accurate.

Sensor refresh (Hz)

UI label: Sensor refresh (Hz)
Range: 0.1–30.0 (default 2.0)
Meaning: Target rate at which native and cached sources are re-sampled into the runtime values the graphs and gauges read (e.g. how often the Lua side refreshes SRC[] /equivalent from Conky parses and cache files).

What it affects

  • How quickly a ring or text number changes after the system changes
  • Load from repeated ${cpu}, ${mem}, cache file reads, etc.
  • Interaction with noisy sensors (higher Hz can make needles jitter more unless you add Smooth)

What it does not replace

Per-source polling still has its own rules:

Mode Who paces the work
Native Conky vars (${cpu}, ${mem}, …) Sensor refresh + Conky’s own update loop
execi external scripts Conky ${execi N script} interval on the node
daemon scripts start.sh loops (poll_interval on the node)
Album art Always daemon-style image fetch

Sensor refresh is the Studio-wide “how often do we care about new numbers in the draw world,” not a rewrite of every script’s timer.

Guidance

Situation Typical Hz
Desktop monitoring, calm UI 1–2
Fast CPU/GPU meters 2–5
Network sparklines that should feel live 4–10
Matching a very high FPS “telemetry” look up to ~15–30 (costly)

Going above ~5–10 Hz rarely improves useful accuracy for thermals or weather; it mainly increases work and jitter.

How they work together

                    ┌─────────────────────────┐
  System / scripts  │  poll on their own pace │
                    └───────────┬─────────────┘
                                │
                    Sensor refresh (Hz)
                    re-read into HUD values
                                │
                                ▼
                         gauges/text/graphs
                                │
                    Draw rate (FPS)
                    Cairo paints the frame
                                │
                                ▼
                           screen pixels

Example

  • FPS = 30 → glow and orbits look smooth
  • Sensor refresh = 2 Hz → CPU % and temp update twice per second
  • Weather daemon interval = 1800 s → weather text still only changes every 30 minutes

The glow does not force weather or temp to poll at 30 Hz.

Live Preview vs installed theme

Live Preview Manager / start.sh
Draw path Real Conky on a scratch build Real Conky
Daemon scripts One synchronous prime per rebuild (no long-lived while loops while Studio is open) Full background loops from start.sh
execi sources Same as standalone Same
FPS/sensor refresh Taken from the Canvas node of the project being previewed Same values baked into the built theme

Closing Studio stops the preview process only. Themes you started from Manager keep running with their own FPS and sensor settings.

Practical recipes

Goal Canvas settings Extra tips
Laptop-friendly FPS 10–15, sensors 1–2 Hz Prefer daemon sensors with longer intervals
Smooth sci-fi chrome FPS 30–60, sensors 2–4 Hz Orbit/radar driven by CPU as trigger, not 60 Hz sampling
Steady gauges FPS 20–30, sensors 2 Hz Add Smooth (EMA) on noisy sources
Fast net meters FPS 30, sensors 5–10 Hz Optional Data Rate Format for text; sparkline for shape
Thermals FPS whatever you like for chrome, sensors 1–2 Hz Map Range + Hysteresis for LEDs, not higher Hz

Related Canvas settings (not FPS, but nearby)

Property Role
Width / Height Logical HUD size in pixels (more pixels → more Cairo work per frame)
Window layering auto / normal / desktop / dock — resolved with session detection for Wayland/X11
Transparent background Needs a compositor for true alpha; not a performance dial
Gap X / Y, alignment Placement on the desktop only

Session limits (e.g., GNOME Mutter Wayland cannot host overlays) are reported under Tools → Hardware & Session; they do not change how FPS vs sensor Hz are interpreted, but they can block the HUD from appearing at all.

Summary

  • Draw rate (FPS) = how often the picture is painted.
  • Sensor refresh (Hz) = how often the numbers behind the picture are refreshed.
  • Keep FPS high only for motion you care about; keep sensor Hz modest unless the data must move fast.
  • Script poll_interval / execi still own external command cost; Canvas sensor Hz does not replace them.

See also: Theme start.sh and theme.json, Node Reference — Sources, Hardware & Session (in-app).

Clone this wiki locally