GDK3/GTK3窗口更新的精确定时 [英] Precision timing of GDK3/GTK3 window update

问题描述

我有一个使用GTK用C编写的应用程序(尽管该语言对于该问题可能并不重要).

I have an application written in C using GTK (although the language is probably unimportant for this question).

此应用程序具有一个全屏显示的gtk_window和一个gtk_drawing_area.对于绘图区域，我已经通过gtk_widget_add_tick_callback注册了一个滴答回调，该滴答仅在每个滴答都调用gtk_widget_queue_draw.在绘图区域draw回调中，我以固定的时间间隔(例如，以1Hz从黑色变为白色)更改整个窗口的颜色.

This application has a fullscreengtk_window with a single gtk_drawing_area. For the drawing area, I have registered a tick callback via gtk_widget_add_tick_callback which just calls gtk_widget_queue_draw every tick. Inside the drawing area draw callback, I change the color of the entire window at regular intervals (e.g., from black to white at 1Hz).

说在这次对绘制回调的调用中，我想将窗口从黑色更改为白色.我想知道实际在屏幕上绘制更改的准确时间(精确到毫秒)(理想情况下，与CLOCK_MONOTONIC相同).我认为这与tick回调中可用的GdkFrameClock并不相同，据我所知，它与帧的时间有关，而不是帧实际在屏幕上显示的时间.

Say that in this call to the draw callback I want to change the window from black to white. I would like to know the precise time (down to the nearest ms) that the change is actually drawn on the screen (ideally in the same units as CLOCK_MONOTONIC). I don't think this is the same thing as the GdkFrameClock available in the tick callback, which, as I understand it, is about the time of the frame, not the time when the frame is actually displayed on the screen.

如果我只是在绘图回调中测量CLOCK_MONOTONIC时间，然后使用光电二极管测量实际更改是通过附加的A2D进行的，则可以理解，实际更改是由于多次刷新而导致的显示延迟间隔(在我的情况下，刷新3个屏幕).

If I just measure the CLOCK_MONOTONIC time in the drawing callback, and then use a photo-diode to measure when the actual change is via an attached A2D, the actual change is the display is understandably delayed by a number of refresh intervals (in my case, 3 screen refreshes).

作为总结:如果我在GTK小部件的绘制回调中，是否有任何方法可以知道显示器以CLOCK_MONOTONIC单位实际显示在显示器上的时间?或者，是否有一种方法可以阻塞一个单独的线程，直到我关心的特定重绘实际上显示在屏幕上为止(我可以像wait_for_screen_flip()这样编写的功能)?

Just as a summary: if I am in a GTK widget draw callback, is there any way to know the time when the display will actually be shown on the monitor in the units of CLOCK_MONOTONIC? Or alternatively, is there a way that I can block a separate thread until a specific redraw that I care about is actually displayed on the screen (a function I can write like wait_for_screen_flip())?

更新:理想情况下，相同的解决方案适用于任何Linux合成器(X11或Wayland)，这就是为什么我希望使用GTK/GDK解决方案来抽象出合成器.

Update: Ideally, the same solution would work for any Linux compositor (X11 or Wayland), which is why I am hoping for a GTK/GDK solution, where the compositor is abstracted away.

推荐答案

我刚遇到 https://developer.gnome.org/gdk3/stable/gdk3-GdkFrameTimings.html#gdk3-GdkFrameTimings.description 说

I just came across https://developer.gnome.org/gdk3/stable/gdk3-GdkFrameTimings.html#gdk-frame-timings-get-presentation-time which seems to do just like what you want and is part of Gdk. I do not know how to use it nor have I seen some example of it, but https://developer.gnome.org/gdk3/stable/gdk3-GdkFrameTimings.html#gdk3-GdkFrameTimings.description says

GdkFrameTimings中的信息对于将视频与事件或音频流进行精确同步以及测量应用程序显示的质量指标(例如延迟和抖动)非常有用.

The information in GdkFrameTimings is useful for precise synchronization of video with the event or audio streams, and for measuring quality metrics for the application’s display, such as latency and jitter.

这篇关于GDK3/GTK3窗口更新的精确定时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！