c - 重复太快时，GTK3 有时会忽略 gtk_widget_queue_draw？

Question

我有一个应用程序可以进行一些模拟，并呈现结果。因为渲染有时会很慢，所以我将其分离到另一个线程中，主线程在准备就绪后调用 gtk_widget_queue_draw。如果它还没有完成绘制，额外的请求将被丢弃(因为 queue_draw 只会使它无效，并且不可能“更多”无效)。

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

我刚刚遇到了一个不同的问题，我不明白为什么会这样:一个足够简单的模拟和渲染(6 条 5 点线)导致它崩溃。

前几个步骤(我到处都看到了大约 60 到 400 个)渲染良好(在几分之一秒内)，直到一个步骤渲染两次。之后，它会忽略 queue_draw，直到我执行类似在渲染窗口上拖动一个窗口的操作，然后它重新启动(直到它再次中断)。

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

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

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

Answer 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 调用的锁。