问题描述
我有一个使用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#gdk-frame-timings-get-presentation-time 这似乎和您想要的一样，并且是Gdk的一部分.我不知道如何使用它，也没有看到它的示例，但是 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
这篇关于GDK3/GTK3窗口更新的精确定时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！