Частичное использование видеокарты AIMP-ом.

[Kibermanick]

Недавнее обсуждение в другой теме надоумило меня на такие мысли.

Помниться несколько лет назад(возможно даже десять лет назад) уже обсуждался вопрос о переносе графической части плеера на обработку видеокартой и одной из причин отказа тогда было то что максимальный размер текстуры не может превышать 1024х1024 пикселей. А как дела обстоят если напрягать видеокарту ситуативно отдельными частями скина? Я знаю что в различных графических фреймворках например в qt есть такой компонент как OpenGL-контекст, который может встраиваться в общий макет приложения. Или например в веб дизайне можно использовать div с WebGL в качестве фильтр-эффекта для фона или просто в качестве фона. Можно ли реализовать OpenGL компонент в скиндвижке AIMP-а? Сделать например компонент по образу блура который берет фон в качестве собственной текстуры(массив пикселей), у которого есть входные переменные взятые например с помощью связей в редакторе связей и редактируемый код шейдера. Таким образом можно было бы иначе реализовать тот же блур убрав его обработку с процессора, ну и конечно же неограниченное количество визуальных эффектов разной сложности фантазии. Это позволило бы реализовывать сложные визуальные эффекты такие как например модный нынче LiquidGlass, хроматическая аберрация, ну и конечно же всякие спектрографы реагирующие на звук, и прочее на что фантазии хватит. Есть правда еще такой вопрос, какова будит задержка отрисовки такого компонента? Все компоненты так или иначе себя отрисовывают последовательно и тратят на это время, большая ли будит задержка ожидания возврата текстуры из видеокарты в общий поток отрисовки? Что думаете?

одной из причин отказа тогда было то что максимальный размер текстуры не может превышать 1024х1024 пикселей.

Кстати где-то видел инфу что хоть размер текстуры таков но количество передаваемых одновременно слоев по 1024х1024 там большое. Если вдруг эта инфа кому-то нужна.

[DarkDrawKill]

думаю стоит отправить в предложения

Кстати где-то видел инфу что хоть размер текстуры таков но количество передаваемых одновременно слоев по 1024х1024 там большое. Если вдруг эта инфа кому-то нужна

как я знаю кадры аниматоров передаются сплошной текстурой поэтому и не влизает

[Artem]

В своё время я игрался с DirectX, максимальный размер текстуры зависит от конкретной видео карты и драйверов к ней. На моей машине было 16200 пкс, но проблема в том, что текстура аниматоров, как правило, занимают куда больше.

Временное переключение контекста не даёт ускорения. Во-первых, чтобы получить буст, нужно выводить графику напрямую на экран, если же выводить не на временный буфер (битмап) - фпс падает в разы. Во-вторых, DirectX не допускает вывод графики без подложки (т.е. с попиксельной полупрозрачностью), а для наших скинов это критично

[DarkDrawKill]

Временное переключение контекста не даёт ускорения. Во-первых, чтобы получить буст, нужно выводить графику напрямую на экран, если же выводить не на временный буфер (битмап) - фпс падает в разы. Во-вторых, DirectX не допускает вывод графики без подложки (т.е. с попиксельной полупрозрачностью), а для наших скинов это критично

Единственное преимущество это поддержка шейдеров и тс подразумевает именно это только в отличии плагинов визуализации как поддержка со стороны скин движка
незнаю поддерживает ли OpenGL полупрозрачность но как для отдельного контрола я думаю это не критично будет

[Artem]

для отдельного контрола я думаю это не критично будет

А как оно будет работать? У самого окна ж композинг включён

[DarkDrawKill]

А как оно будет работать? У самого окна ж композинг включён

прям тонкостей я не знаю
я гуглил подобное и где упоминается говорится что opengl поддерживает композинг (через фрейм буфера + шейдеры) и работу с эффектами (прозрачность, транформация и тп)
если нет будет просто чёрный квадрат на котором всё рисуется (или сделать как свойство для графических текстур по типу рендеруемой крышки или прям внутрь текстуры)

[Artem]

через фрейм буфера

Надо делать пример и замерять производительность. DirectX в буфер рендерит заметно медленнее, чем на экран

[Kibermanick]

думаю стоит отправить в предложения

Захотелось сначала обсудить в формате общения, вдруг я глупость несусветную сморозил😀

В своё время я игрался с DirectX, максимальный размер текстуры зависит от конкретной видео карты и драйверов к ней. На моей машине было 16200 пкс, но проблема в том, что текстура аниматоров, как правило, занимают куда больше.

Ну 16200 это размер одной текстуры правильно? А если разбить аниматор по кадрам и передавать массив кадров пакетом? Это же все ровно будит единая структура данных в виде массива кадров. Интересно как на вулкане сделали так что там в принципе делается единая мега текстура из всех текстур сшитых в одну🤔

Временное переключение контекста не даёт ускорения. Во-первых, чтобы получить буст, нужно выводить графику напрямую на экран, если же выводить не на временный буфер (битмап) - фпс падает в разы. Во-вторых, DirectX не допускает вывод графики без подложки (т.е. с попиксельной полупрозрачностью), а для наших скинов это критично

Блин как всегда всё работает с обратной стороны. Странно конечно что нет поддержки вывода прозрачности но, в том что я предлагаю возвращаемая текстура не должна иметь прозрачность в принципе, там главное что бы передавался снимок из под элемента и возвращался он же но с изменениями. А так непонятно там что данные не по 32 бита на пиксель? Куда альфу дели?

Как я это вижу: В видеокарту передается массив пикселей , ну или два массива один изначальная текстура а второй массив нулей с тем же размером что и текстура, в процессе работы шейдер берет данные пикселя с первого массива производит математику над ним и записывает результат во второй массив, так как все пиксели обработаются параллельно это не должно занимать много времени, правда я так и не понял почему при входном массиве 32х битных элементов массива нельзя вернуть те же массивы 32х битных элементов это же просто числа над которыми произвели математику.

[Kibermanick]

Кстати, всякие графические и видео редакторы для ускорения своей работы используют OpenCL. Это что за фрукт? Может это дело использовать?

[Artem]

Блин как всегда всё работает с обратной стороны. Странно конечно что нет поддержки вывода прозрачности но, в том что я предлагаю возвращаемая текстура не должна иметь прозрачность в принципе, там главное что бы передавался снимок из под элемента и возвращался он же но с изменениями. А так непонятно там что данные не по 32 бита на пиксель? Куда альфу дели?

Нет, текстуры могут быть полупрозрачные и композинг работает без проблем. Проблема кроется в том, что DirectX контекст нельзя завести поверх окна с полупрозрачностью - там идёт черный фон по всей области контекста

[Kibermanick]

Можно делать графику но нельзя применить ее где и как хочешь... Странно это же вроде базовые вещи, должно работать.

[Kibermanick]

Вот что сказала Алиса:

Разберу проблему подробно — почему возникает ограничение и как его обойти с сохранением альфа‑каналов.

## Почему возникает проблема

DirectX (особенно в режимах `D3D11` или `D3D9`) не поддерживает нативное наложение рендера поверх окна с **прозрачностью/полупрозрачностью** (alpha‑blend), потому что:

1. **Окно с альфа‑каналом** требует от оконного менеджера (DWM в Windows) композитинга — смешивания слоёв с учётом прозрачности.
2. **DirectX‑контекст** по умолчанию рендерит в буфер без учёта внешнего альфа‑канала окна — он либо полностью перекрывает фон, либо игнорирует его.
3. **Конфликт режимов**: DWM отключает аппаратное ускорение для окна, если оно использует нестандартную прозрачность, что ломает инициализацию DirectX.

---

## Решения

### Вариант 1. Использование `WS_EX_LAYERED` + `UpdateLayeredWindow`

Подходит для Windows (Vista+), сохраняет альфа‑канал.

**Шаги:**

1. Создайте окно с расширенным стилем `WS_EX_LAYERED`.
2. Инициализируйте DirectX‑контекст **без** привязки к окну (используйте `D3DPRESENT_PARAMETERS` с `hDeviceWindow = NULL`).
3. Рендерите сцену в текстуру (`IDirect3DSurface9` или `ID3D11Texture2D`).
4. Скопируйте результат в системный буфер с альфа‑каналом.
5. Вызовите `UpdateLayeredWindow()`, передав буфер с RGBA‑данными.

**Плюсы:**
* полная поддержка альфа‑канала;
* работает с DirectX 9/11.

**Минусы:**
* низкая производительность при частых обновлениях;
* требуется ручное копирование данных из видеопамяти в системную память.

**Код (упрощённо):**
```cpp
// Создание окна
HWND hwnd = CreateWindowEx(WS_EX_LAYERED, ...);

// Рендеринг в текстуру DirectX
pDevice->SetRenderTarget(0, pTextureSurface);
// ... отрисовка сцены ...

// Копирование в системный буфер
pTexture->LockRect(&lockedRect, NULL, D3DLOCK_READONLY);
// Заполнение BITMAPINFO + альфа‑канал
UpdateLayeredWindow(hwnd, hdcScreen, &pos, &size,
                     hdcMemory, &srcPos, 0, &blend, ULW_ALPHA);
pTexture->UnlockRect();
```

### Вариант 2. `D3D_SWAPE_EFFECT_DISCARD` + `BackBuffer` с альфа‑форматом

Для DirectX 9.

**Шаги:**

1. При создании устройства укажите формат буфера с альфа‑каналом: `D3DFMT_A8R8G8B8`.
2. В `D3DPRESENT_PARAMETERS` установите:
   * `SwapEffect = D3DSWAPEFFECT_DISCARD`;
   * `hDeviceWindow` — ваш полупрозрачный window.
3. Очищайте буфер с учётом альфа‑значения:
   ```cpp
   device->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_ARGB(128, 0, 0, 0), 1.0f, 0);
   ```
4. Отключайте `DWM` композитинг для окна через `DwmSetWindowAttribute()`.

**Плюсы:**
* высокая производительность;
* нативный рендеринг.

**Минусы:**
* возможны артефакты на границах окна;
* требует точной настройки DWM.

### Вариант 3. DirectX 11 + `DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING`

Для Windows 10+.

**Шаги:**

1. Создайте swap chain с флагом `DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING`.
2. Используйте формат `DXGI_FORMAT_B8G8R8A8_UNORM`.
3. Настройте `IDXGISwapChain::SetFullscreenState(FALSE, nullptr)` для оконного режима.
4. Перед рендером установите viewport с учётом прозрачных границ.
5. В шейдере явно задавайте альфа‑значение:
   ```hlsl
   float4 PS(PS_INPUT input) : SV_Target {
       return float4(color.rgb, 0.5); // 50% прозрачности
   }
   ```

**Плюсы:**
* поддержка современных версий DirectX;
* плавность при VSync off.

**Минусы:**
* требует Windows 10 1903+;
* возможны разрывы изображения.

### Вариант 4. Отдельный прозрачный слой + композитинг

**Архитектура:**

1. Создайте **два окна**:
   * основное (полностью прозрачное, `WS_EX_TRANSPARENT`);
   * дочернее (для DirectX, без прозрачности).
2. Позиционируйте дочернее окно внутри основного.
3. Используйте `SetLayeredWindowAttributes()` для управления прозрачностью.
4. Синхронизируйте рендер дочернего окна с обновлением основного.

**Плюсы:**
* гибкость настройки;
* разделение логики рендера и прозрачности.

**Минусы:**
* сложность синхронизации;
* накладные расходы на управление окнами.

---

## Рекомендации по выбору

| Сценарий | Лучший вариант |
|--------|-------------|
| Статичная сцена / низкая частота кадров | Вариант 1 (`UpdateLayeredWindow`) |
| Высокая производительность, Windows 7+ | Вариант 2 (DX9 + альфа‑буфер) |
| Современные системы, Windows 10+ | Вариант 3 (DX11 + tearing) |
| Сложное UI с анимациями | Вариант 4 (отдельный слой) |

---

## Важные нюансы

1. **Проверка поддержки**: перед инициализацией проверяйте:
   * поддержку формата с альфа‑каналом через `CheckDeviceFormat()`;
   * доступность `DWM` через `DwmIsCompositionEnabled()`.
2. **Синхронизация**: при использовании `UpdateLayeredWindow()` избегайте частых вызовов — группируйте обновления.
3. **Отладка**: включите `D3DERR_INVALIDCALL` и `DXGI_ERROR_DEVICE_REMOVED` для отслеживания ошибок.

Надеюсь там есть что то полезное

[Artem]

Как я уже выше говорил, рендеринг в текстуру работает, но очень сильно теряет в производительности.

[Kibermanick]

Печально

[«G-Li†ch»]

четверть века назад ещё Unreal Engine 2 поддерживал текстуры 2048×2048, хоть и тогда чаще использовались 16-разрядные DXT (хоть какое-то сжатие)… Вот только с "современным дизайном" уже и 8 бит много — лучше просто в пару десятков байт записать опкоды что куда на сколько и как закрашивать (векторно)…
Помню ещё тогда выводящиеся фильмы (видеоданные) не удавалось захватить PrintScreen`ом — вместо "стоп-кадра" в Paint вставляло "черноту", позже уже нашёлся проигрыватель, способный "захватить" кадр… Подозреваю, "трюк" с захватом экрана и последующим наложением полупрозрачной текстуры ещё сильнее бы снижало быстродействие…
Но меня скорее смущает другое… Всё тот же VirtualDJ 8 (2018, 2020) постоянно обновляет уже выведенную на экран обложку, даже если никакие элементы в ней не переключались, и соответственно "комп. прогревает" даже тупо "в простое" (только свернув окно или перекрыв его другим окном хоть как-то "охлаждает" ), ну хотя б можно переключиться на "экспериментальный" движок, и тогда обновляет только при появлении/анимировании (мигании) элементов окна, а если например какую-либо область сменить (переключить) другой с меньшим кол-вом кнопок/крутилок, то остаются видны части старых текстур от "перекрытых" (не)нажатых кнопок/(не)светящихся индикаторов — "замазать" можно каким-нибудь "окошком" (протянуть по экрану), но быстрее уже ткнуть какой-нибудь ALT, на котором назначено действие «setting ExperimentalSkinEngine "no" while_pressed»… Другое дело, что в новых версиях меня бесило, когда при нажатии "play"соседнего "стола" (deck) воспроизведение обоих столов "стопорилось" где-то на треть секудны (возникала пауза)… Связано ли это с прерываниями на видеокарту (точнее, обращение к видеодрайверу) — не понятно (т.к. частенько мне доводится наблюдать прерывания в звуке при использовании дискретки, причём на нескольких компах/ноутах), т.к. даже при выключенном "экспериментальном движке" такая же проблема… И да, банально включив/выключив монитор тоже приводит как "затыканию" звука… хотя тут ещё возможно виноват HDMI/DP (якобы появляется/пропадает ещё одно аудиооборудование, причём даже если в них ничего и не было подключено, т.е. всё это время использовался исключительно аналоговый VGA/DVI-I) — вот тут уже точно виноваты видеодрайверы (что у AMD, что NVIDIA… благо на старых Intel`овских интеграшках (без HDMI) такой проблемы не было)