Переместить выпавший кусок окна

Что отражает моё мнение об этом интерфейсе.

я за тредом не следил, xdotool и аналогичные тулзы не помогли в итоге?

На его месте то, что должно быть под ним, или чёрный квадрат?

В окне Avidemux на месте превью — белый прямоугольник. В том месте, где я вижу превью — нижележащее окно.

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

xdotool и аналогичные тулзы не помогли в итоге?

Они что-то видят в том районе и даже могут его двигать, но изображение не двигается.

Не понял, если сейчас уже всё завершилось то откуда взялось превью на экране?

но изображение не двигается.

медицина здесь бессильна

Не понял, если сейчас уже всё завершилось то откуда взялось превью на экране?

Avidemux всё ещё запущен. Основное окно можно двигать, прокручивать фильм, но прямоугольник превью висит на одном месте. Я пока ничего не закрывал, т.к. интересно, что ещё можно попробовать.

А «вроде бы скриншоты с превью» ты не сохранял? Можно ещё раз сжатие какое-нить запустить и проверить.

Ну, как бы то ни было, по текущей ситуации (на скриншоте вместо превью нижележащее окно), mittorn, вот смотри, скриншотер читает root window и в нём нарисовано нижележащее под оверлеем окно. То есть оверлей находится вне root window, как минимум сейчас. А все окна - внутри него (окон вне root не может быть же), так что оверлей не может быть окном.

Точнее, левый верхний угол прямоугольника превью зафиксирован там, где был в момент запуска. Если двигать окно — превью остаётся на месте. Если менять ширину окна — размер превью меняется. (А высоту — нет.)

Ещё можно найти скриншотер который работает не через иксы а через драйвер видеокарты и им заскринить скорее всего уже с превью.

Может он через xvideo рисуется? Это можно через xvattr посмотреть:
https://linux.die.net/man/1/xvattr
xv всё равно работает через Drawable, потому требует окна, но может тут просто иксы баганули

https://github.com/w23/obs-kmsgrab/ можно попробовать

А «вроде бы скриншоты с превью» ты не сохранял?

Не сохранил.

Можно ещё раз сжатие какое-нить запустить и проверить.

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

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

Раз превью исчезло, эксперименты заканчиваю. Можете написать, что попробовать, если ошибка проявится в следующий раз.

А можно всё-же тогда побольше информации, что за драйвер, используется ли композитор, а то мы тут спорим и в угадайку играем. Пока что мне вариант с багом xvideo кажется наиболее правдоподобным т.к результат на скриншот не попадает

А можно всё-же тогда побольше информации, что за драйвер,

Совсем забыл. nvidia 590.44.01, закрытый.

используется ли композитор,

В System Settings отключён.

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

Что должен показать xvattr?

Тогда возможно в драйвере есть какие-то механизмы оверлеев. Скорее всего баганула его реализация xv. В отличие от открытых драйверов nvidia действительно запаривались с оптимизацией и могли использовать аппаратные оверлеи.
В xvattr будут настройки портов вывода видео. Какие настройки у nvidia - не знаю, но скорее всего можно будет покрутить яркость, контраст и увидеть, отреагирвоал ли оверлей

Странно, что никто не попробовал до сих пор в исходниках Avidemux посмотреть через что рисуется превью.

Вот какие у них варианты рендера бывают:

typedef enum
{
    RENDER_XV = 1,
    RENDER_SDL = 2,
    RENDER_DIRECTX = 3,
    RENDER_VDPAU = 4,
    RENDER_QTOPENGL = 5,
    RENDER_LIBVA = 7,
    RENDER_DXVA2 = 8,
    RENDER_DEFAULT = 9,
    RENDER_GTK = 10,
    RENDER_SDL3 = 11,
    RENDER_LAST
} ADM_RENDER_TYPE;

И есть у меня подозрение, что где-то это настраивается. Даже не поленюсь, поставлю avidemux на посмотреть.

Ну да, так и есть Настройки - Вывод. По умолчанию стоит VDPAU.

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

Я как-то наткнулся на баг, когда обновление куска окна внутри обычного приложения на gtk3 портило часть пикселей вне окна.

Звучит как вранье, понимаю. Было это несколько лет назад. Я тогда себе голову решил не забивать, а после пары обновления Арча оно исчезло. Как в том меме - может оно исчезнет, если я не буду на это смотреть. Помогло. 😁

VDPAU (Video Decode and Presentation API for Unix) — это API, разработанное NVIDIA, которое позволяет переносить часть процесса декодирования видео и его постобработки на сторону видеокарты, разгружая процессор. Метод наложения (overlay) в VDPAU используется по возможности, а побитовое копирование (blit) применяется в крайнем случае.

Вот и вывод через overlay нашелся.

Ну что ты за название темы сделал!!! прочитал как «Переместить выпавший кусок г**на»

Не ты один…

Не, когда речь идёт о баге, всё и так понятно.
Вопрос что за API это такое был как раз в контексте того, можно ли рисовать так не в рамках какого-то бага. Тот же XV не позволяет это делать - он требует на экране сначала расположить drawable. Для vdpau я точно не знаю, есть ли способы вывести в обход x11 таргета. Если нет - то VdpPresentationQueueTargetCreateX11 тоже работает именно с drawable и должен автоматически переключиться с оверлея на блиттинг если окно хоть что-то перекрывает (но некоторые реализации, такие как vdpau_sunxi используют chroma key), так что подобная проблема возможна лишь в случае бага.
Драйвера ati/radeon использовали chroma key для xv. опять же это исключает ситуацию с застрявшим прямогуольником даже если оно забагуется, видно только те пиксели, которые рисуются поверх тёмно-синего RGB(0,1,2) цвета, т.е этот кусок оквна бы не застрял на экране, а просто было бы видно этот цвет на месте превью. Но т.к эти все старые драйвера навряд ли заработают с актуальной месой, а nvidia нуждается в отдельном умоминании - я конечно такие API сразу исключил. У реализации xv-glamor такой проблемы нет - она работает через композитинг.
Остальные реализации (vaapi, opengl, etc) используют стандартный dri2/dri3 путь и тоже не должны вызывать подобной ситуации. В общем, все пути всё равно требуют drawable и исключают ситуацию «не окно»