我已经实现了一个同步块(synchronized block)
,它使用input_items
值在其work
函数内进行绘制。现在的问题是绘图机制对于输入流来说不够快(input_items
的值不断变化)。
我已尝试尽可能简化代码并添加注释。这是:
....
import matplotlib
from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as FigCanvas
from matplotlib.backends.backend_wx import NavigationToolbar2Wx
from matplotlib.figure import Figure
temp = ''
class xyz(gr.sync_block):
def __init__(self,parent,title,order):
a = []
self.count = 1
gr.sync_block.__init__(self,
name="xyz",
in_sig=[numpy.float32,numpy.float32],
out_sig=None)
self.win = xyzPlot(parent) #I have a Top Block(wxFrame). I am just making it the parent of xyzPlot(wxPanel) here.
def work(self, input_items, output_items):
global temp
if (self.count == 1):
temp = input_items+list()
bool = not(np.allclose(temp,input_items))#bool will be true if the value of `input_items` changes.
.......
#the code that evaluates z1,z2 depending on the value of input_items
.......
if ( bool or self.count == 1 ):
#If bool is true or it is the first time then I am calling plot() which plots the graph.
self.win.plot(tf(self.z1,self.z3),None,True,True,True,True)
self.count = 0
temp = input_items+list()
return len(input_items[0])
class xyzPlot(wx.Panel):
def __init__(self, parent, dB=None, Hz=None, deg=None):
wx.Panel.__init__(self , parent , -1 ,size=(600,475))
self.fig = Figure()
self.axes = self.fig.add_subplot(111)
def plot(self, syslist, omega=None, dB=None, Hz=None, deg=None, Plot=True, *args , **kwargs):
self.axes.clear() #I clear the graph here so that new values can be plotted.
.....
self.axes.semilogx(omega,mag,*args,**kwargs)
self.canvas = FigCanvas(self, -1, self.fig)
self.canvas.draw()
正如你所看到的,我正在使用 wxPython,但是每当我太快地更改 input_items
的值时,面板都会卡住(如果我缓慢地更改它,则效果很好)。有什么建议吗?我对此很陌生。
最佳答案
引用another answer我给了:
This will quickly also get a multithreading problem. To be clear: What you're trying to do (call a plotting function from a block thread) is problematic and usually won't work.
问题在于您正在复杂的多线程环境中工作:
- 每个 GNU Radio block 都在自己的线程中工作
- WX Gui 主循环不断运行以更新屏幕。
您在这里所做的是,从 GNU Radio block 线程中更改窗口中显示的内容。这是一件坏事,因为它改变了 WX Gui 线程上下文中的内容。如果这些更改不冲突,并且 WX Gui 线程在您更改数据时不访问此类数据(在某些时候,它必须访问它 - - 否则,没有人会更新你的窗口)。
这是所有类型更新的 GUI 的共同问题,而不仅仅是 GNU Radio!
这种情况是否发生只是一个概率问题:在缓慢更新的显示中,发生冲突的概率很低,但当您经常更新时,它会接近 1。
现有的可视化是用 C++ 编写的,并且非常小心地以正确的方式做事——也就是说,让你的 Gui 工具包(在你的例子中是 WX,尽管我明确建议,并且已经建议,远离那个) )知道需要更新,然后为 WX 提供一个函数来在自己的线程中更新显示。
关于python - 由于 GNU Radio block 的快速输入流而导致绘图卡住,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31068361/