当重复太快时，GTK3 有时会忽略 gtk_widget_queue_draw？答案

【问题标题】：GTK3 sometimes ignores gtk_widget_queue_draw when repeated too quickly?当重复太快时，GTK3 有时会忽略 gtk_widget_queue_draw？
【发布时间】：2012-11-27 21:09:34
【问题描述】：

我有一个应用程序可以进行一些模拟并呈现结果。因为渲染有时会很慢，所以我将它分离到另一个线程中，一旦准备好，主线程就会调用gtk_widget_queue_draw。如果还没有画完，多余的请求就会被丢弃（因为queue_draw只会使其失效，不可能“更多”无效）。

结果是，对于大型复杂系统，模拟最大化一个线程，渲染最大化另一个线程，一切正常。

我刚刚遇到了一个不同的问题，但我不明白为什么会这样：足够简单的模拟和渲染（6 条 5 点线）会导致它中断。

前几个步骤（我在任何地方都看到了大约 60 到 400 个）渲染良好（在几分之一秒内），直到一个步骤渲染两次。之后，它会忽略queue_draw，直到我在渲染窗口上拖动一个窗口，然后重新启动（直到它再次中断）。

如果我人为地减慢请求速度（usleep(10000) 已经足够了），这不会发生。

然而，这是一个完全不可接受的解决方案，因为不允许显示的过程干扰正常的模拟线程（无延迟、无互斥体等）。我需要一个使渲染线程“尽可能好”的解决方案，因为它正在处理易失性数据。它不必非常准确——我真的不在乎一帧渲染是否有点错误（帧 i 的一半，i+1 的一半很好），只要它确实渲染。

为什么会发生这种情况，我该如何解决？

【问题讨论】：

“主线程”是事件循环线程吗？另外，第一段中的“它”太多了，令人困惑，你能澄清一下吗？
事件循环被推送到辅助线程pthread_create(&renderThread,NULL,gtk_main_wrapper,NULL);，其中void* gtk_main_wrapper() { gtk_main(); return NULL; }。主线程在完成一个步骤时抛出一个queue_draw，假设额外的请求不是问题。
根据@liberforce，添加锁定。见这里：blogs.operationaldynamics.com/andrew/software/gnome-desktop/…
hmm.. 问题是我需要一种非阻塞的方式来告诉 GUI 重绘自己。 IIRC 当我有锁时，它同步了两个线程，这是不可接受的。
@DanielGibbs 我真的没有。我能想到的最好的方法是 if ( time=getTime() < lastTime+MIN_INTERVAL) { gtk_widget_queue_draw(myWidget); lastTime=time;} 包装器，以确保它不会被调用超过，例如，每 10 毫秒 (100fps)。这是一种解决方法，而不是解决方案——但它或多或少是有效的。

标签： c gtk gtk3

【解决方案1】：

你有一个竞争条件。

自 GTK3.6 起，您需要像这样调用gtk_widget_queue_draw：

g_idle_add((GSourceFunc)gtk_widget_queue_draw,(void*)window);

或者像这样：

gdk_threads_add_idle((GSourceFunc)gtk_widget_queue_draw,(void*)window);

window 是你要绘制的GtkWidget*。

如果您不确定应用使用的库或代码是否使用已弃用（自 3.6 起）gdk_threads_enter 和 gdk_threads_leave 函数，请使用 gdk_threads_add_idle。

见：https://developer.gnome.org/gdk3/stable/gdk3-Threads.html#gdk3-Threads.description

在 GTK3.6 之前，必须使用 gdk_threads_enter 和 gdk_threads_leave 来获取 GTK 调用的锁。

【讨论】：

【解决方案2】：

您是否使用 gdk_threads_enter/gdk_threads_leave 锁定了线程中的 UI 调用？也许添加代码示例也会有所帮助...

【讨论】：