# TRANVIEW PRO

## Обзор

Это высокопроизводительное специализированное ПО, предназначенное для мгновенной визуализации и анализа сверхбольших массивов данных (сотни миллионов точек), полученных в результате переходных процессов (TRAN-анализа) в SPICE-симуляторах EDA.

Проект решает фундаментальную проблему традиционных просмотрщиков: падение производительности, зависания и чрезмерное потребление ОЗУ при работе с файлами объемом в десятки гигабайт.

## Особенности

* Zero-Copy & Memory Mapping

Позволяет программе мгновенно открывать файлы любого размера (>30GB), не загружая их целиком в оперативную память. Программа стабильно работает даже при жестких лимитах (например, 500 MB RAM). Для систем, где mmap недоступен, предусмотрен фолбэк (Strict Mode).

* Иерархическая индексация (.tidx)

Генерация M4-пирамиды (уровни L1/L2), которая занимает всего ~1.5% от исходного размера файла. Обеспечивает мгновенный зум и навигацию даже при работе с медленных HDD-дисков без необходимости полного сканирования данных.

* Pattern Detection (O(1) рендер)

Анализатор "на лету" распознает тактовые (циклические/PWM) сигналы и константы (например, шины питания). Такие сигналы синтезируются математически за O(1), полностью исключая тяжелые операции чтения с диска при отрисовке.

* Продвинутый Downsampling и SIMD-ускорение

Поскольку на экране всего ~1000-4000 пикселей по горизонтали, отрисовывать миллионы точек бессмысленно. Реализованы Branchless-алгоритмы сжатия на лету с аппаратной векторизацией (AVX2, SSE4.1, ARM NEON):

 * M4 / Min-Max: Безупречный контур сигнала без потери пиков.

 * LTTB / LTTB+: Визуально-ориентированное усреднение.

 * Spline: Сглаживание Catmull-Rom.

 * Auto: Интеллектуальный выбор алгоритма в зависимости от масштаба и наличия индекса.

* Продвинутый UX/UI

Раздельный просмотр сигналов с поддержкой Drag & Drop (перетаскивание графиков), синхронизация осей (X/Y), адаптивный троттлинг FPS для сохранения отзывчивости, темная/светлая темы.


## Технологии и переносимость

Написано на Rust с использованием eframe/egui и rayon. Приложение скомпилировано с упором на максимальную переносимость без "зоопарка" зависимостей (не нужны Qt, GTK и т.д.).

Приложение в том числе тестировалось на Raspberry PI 3 (2016 год, 1 гигабайт оперативной памяти и aarch64 архитектура) и показало более чем хорошие результаты. При использовании софтового рендера (LIBGL_ALWAYS_SOFTWARE=1) приложение даже без построения индекса позволяло работать с графиком в 10 fps размер которого был более 1 террабайта аналоговых данных (рендер O(1) в таком случае неприменим).

Если в Linux запущена графическая сессия, программа сама найдет подходящий бэкенд (поддерживаются Vulkan и OpenGL). Единственная косвенная зависимость на Linux — dlopen для загрузки графических драйверов ОС. В поставке присутствуют сборки под современные и старые версии glibc (от 2.18, Ubuntu 14.04+, т.е. поддержка дистрибутивов от 2013 года), а также Musl (не для дистрибутивов с glibc).

## Планы на улучшение

* Измерительные курсоры и маркеры (полноценный анализ дельт T и V).
* Search Hints (подсказки при поиске сигналов).
* LRU Cache
* Search Hints
* Вывод подробных предупреждений в UI при структурных ошибках в исходном файле данных.

## HOW TO

В поставке по 2 бинарных файла (view, gen) на каждую из платформ.
* gen - консольная утилита для генерации входных данных. См. вывод -h.
* view - сама программа визуализации данных. Достаточно запустить и в интерфейсе выбрать файл для визуализации.

Быстрый старт
```
cd ./build/linux_x86_64_legacy  # Переходим подходящий каталог 
./gen 1000000 inverter data.out # Генерируем тестовый файл на 1 миллион точек
./view
```
Далее в графическом интерфейсе выберите File -> Открыть и укажите data.out.

## Demo WASM (для сайта)

Сборка браузерной demo без открытия файлов — меню «Примеры» (инвертор, импульс, осциллятор, по ~100k точек в RAM). При старте сразу грузится осциллятор.

```
./build-demo-wasm.sh
```

Артефакты: **`./build/web/`** — только `view-demo.js` и `view-demo_bg.wasm` (стабильные имена). Профиль Cargo `release-wasm` + `wasm-opt -z`. Нужны `rustup target add wasm32-unknown-unknown` и `trunk`.

На сайт: положите оба файла и на странице canvas с `id="tranview_canvas"`, затем:

```html
<canvas id="tranview_canvas" tabindex="0"></canvas>
<script type="module">
  import init from "./view-demo.js";
  await init({ module_or_path: "./view-demo_bg.wasm" });
</script>
```

Папка отдельная от нативных `./build/*.tar` — trunk очищает только `build/web`. HTML из trunk после сборки удаляется скриптом.

Локальный просмотр: `trunk serve` (берёт `web/index.html`).

Нативная demo без WASM: `cargo run --release --bin view-demo --features demo`.

Обычный view: `cargo run --release --bin view` (WGPU/sysinfo/zstd только на native-таргете, не на wasm32).

WASM-сборка требует **rustup** с таргетом `wasm32-unknown-unknown` (не standalone «Rust GNU» без wasm). Скрипт `build-demo-wasm.sh` подстраивает PATH под rustup.

Аргументы командной строки view:
    --strictmem - принудительный запуск в Strict Mode (отключение mmap и работа исключительно через потоковое чтение файла). Идеально для тестов в сверхжестких условиях нехватки ОЗУ. По-умолчанию программа пытается использовать всю доступную оперативную память, но при невозможности перейдёт в строгий режим.

    --opengl - принудительный запуск с бэкендом OpenGL (Glow). Отключает сглаживание и прозрачность. Полезно для слабых систем и одноплатных компьютеров (например, Raspberry Pi). По-умолчанию если не будет найден Vulkan будет использоваться OpenGL.

Если графика не смогла инициализироваться (черный экран, то это означает, что необходимо применить программный рендер. Попробуйте:
```
LIBGL_ALWAYS_SOFTWARE=1 ./view
```

## Примечания

В интерфейсе доступна подробная отладочная информация. Параметр "Сжатие" показывает, во сколько раз алгоритмы (M4/LTTB или другие) уменьшили объем данных перед передачей на GPU. "Множитель" показывает сколько точек должны (кроме RAW) отдавать на один пиксель ширины графика.

Потребление памяти: Ресурсы системы (RSS) в интерфейсе могут быть малоинформативны, так как при использовании mmap фактическое потребление ОЗУ контролируется планировщиком ОС.

Чтобы увидеть, насколько хорошо программа работает в стресс-условиях, установите жесткие лимиты через cgroups:
```
systemd-run --scope -p MemoryMax=500M --user ./view
```

Сборки windows_x86_64_gnu и windows_x86_64_win отличаются компилятором. В целом рекомендуется использовать _win. Смотрите так же файл BUILD.md.