У меня есть приложение, написанное на C с использованием GTK (хотя язык, вероятно, неважен для этого вопроса).
Это приложение имеет полноэкранный режимgtk_window с одним gtk_drawing_area. Для области рисования я зарегистрировал обратный вызов тика через gtk_widget_add_tick_callback, который просто вызывает gtk_widget_queue_draw каждый тик. Внутри обратного вызова области рисования draw я меняю цвет всего окна через равные промежутки времени (например, с черного на белый с частотой 1 Гц).
Скажем, в этом вызове обратного вызова отрисовки я хочу изменить окно с черного на белое. Я хотел бы знать точное время (с точностью до мс), когда изменение действительно отображается на экране (в идеале в тех же единицах, что и CLOCK_MONOTONIC). Я не думаю, что это то же самое, что GdkFrameClock, доступный в обратном вызове тика, который, как я понимаю, касается времени кадра, а не времени, когда кадр фактически отображается на экране.
Если я просто измерю время CLOCK_MONOTONIC в обратном вызове чертежа, а затем использую фотодиод для измерения, когда фактическое изменение происходит через подключенный A2D, фактическое изменение заключается в том, что отображение по понятным причинам задерживается на несколько интервалов обновления (в моем случае , 3 обновления экрана).
В качестве резюме: если я нахожусь в обратном вызове отрисовки виджета GTK, есть ли способ узнать время, когда дисплей будет фактически отображаться на мониторе, в единицах CLOCK_MONOTONIC? Или, в качестве альтернативы, есть ли способ, которым я могу заблокировать отдельный поток до тех пор, пока конкретная перерисовка, которая мне небезразлична, действительно не отобразится на экране (функция, которую я могу написать как wait_for_screen_flip())?
Обновление: в идеале одно и то же решение будет работать для любого компоновщика Linux (X11 или Wayland), поэтому я надеюсь на решение GTK/GDK, в котором компоновщик абстрагирован.
