GTK/Cairo的实时绘图性能问题
我目前正在开发一个实时数据绘图解决方案，它能够频繁地接收新数据(最高可达1 1kHz)并以较低的速率执行重绘(例如50 at )。我使用FLTK进行了第一次实现，但是我想尝试一下GTK，因为我以前从未使用过它，对我来说它看起来很有前途。
为了简短起见，我注意到对cairo_stroke()的调用与使用FLTK ( FLTK中没有笔画，fust a fl_line()函数)相比，在绘制线条时花费了大量时间。我试图尽可能限制笔画，但我仍然有5-7倍的渲染时间使用GTK。
在使用DrawingArea时使用GTK/Cairo时，有没有人注意到这样的性能问题？是否有任何线索显示在哪里可以缩短绘图时间？
注意:后端(要绘制的行和文本的计算)完全相同，因为它是在公共基类中执行的。
回答 2
Stack Overflow用户
发布于 2018-04-10 22:10:23
开罗的绘画确实不是很快。有两个主要瓶颈:发出“绘图”信号的频率和开罗如何在引擎盖下画线。
- 在我的工作中，PC部件重绘大约每秒25次，即25 per。在我自己的赎罪中，我没见过比这更多的fps，可能是30或40。对重绘函数给予更多的优先级可能会导致很少调用其他主循环函数。
cairo_line_to是一种非常聪明的绘制方法，它用反混叠、混色、透明等方法绘制线条，并且在精确的像素(坐标为双倍，1 1px垂直线可以占用两个像素)中绘制。
据我所知，有两种方法可以加快绘图速度：
- 使用OpenGL
- 在图像表面定制直线绘制(
cairo_image_surface_get_data并逐像素绘制图像像素)
当然，还优化了您执行的绘图数量，但这并不是完全可伸缩的。
Stack Overflow用户
发布于 2018-04-28 21:20:21
我在https://github.com/pchilds/GtkPlot中有一个Gtk/Cairo绘图库
在我制作它的时候，我设计它是为了绘制大型数据集(10k+)。缺点是代码是痛苦的、不可维护的、被优化的和不受欢迎的。但它完成了任务。我没有调查刷新率，但可能是由它决定的。据我所记得，我没有为每一行划线，但我可能错了。如果点是连在一起的，你可以在一次行程中创建一条路径，把它们全部划掉。
我还没有对FLTK进行比较。
亚历山大提到OpenGL是一个很好的例子。您还可以查看开罗的wayland后端。Wayland是X的另一种选择，它使用OpenGL。
https://stackoverflow.com/questions/49758089
复制相似问题
腾讯云开发者
