You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/architecture.md
+38-2Lines changed: 38 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,9 +5,10 @@ The core goal is: keep navigation/status updates responsive even when image rend
5
5
6
6
## High-level pipeline
7
7
8
-
There are three concurrent “lanes”:
8
+
There are three concurrent "lanes":
9
9
10
10
1.**Main thread** (`src/main.rs`)
11
+
- Loads configuration (`src/config.rs`).
11
12
- Reads key events.
12
13
- Updates application state.
13
14
- Decides when to request rendering.
@@ -78,7 +79,42 @@ This approach:
78
79
`svt` uses a **client-side render cache** only:
79
80
80
81
-**Render cache** (`render_cache` in `App`): Stores decoded/resized/encoded image data.
81
-
- Size controlled by `SVT_RENDER_CACHE_SIZE`(default: 15).
82
+
- Size controlled by `render_cache_size` config (default: 100).
82
83
- LRU eviction when cache is full.
83
84
84
85
The terminal-side cache is **not** relied upon. Each transmit starts with `delete_by_id` to ensure a clean slate. This trades some bandwidth for simplicity and correctness.
86
+
87
+
## Configuration
88
+
89
+
Settings are loaded at startup by `Config::load()` (`src/config.rs`):
90
+
91
+
1. Load from `~/.config/svt/config.toml` (if exists).
0 commit comments