关于算法命名，前两天其实提到过，比如 侯展意 认为在命名方面，可以是功能分类+动词短语。比如fit_least_square的命名会比least_square_fit好，原因是目前自动补全已经支持简写输入，用户想做拟合（fit）的话，输入“fit”，后面不同种类的拟合操作都出来了 。 付老师 补充可以有一个统一的函数api，参数中有method方法来指定类型。

命名这一块我感觉主要参考issue 【意见征求稿：函数库建设方案】
然后二维可能暂时使用pyqtgraph来进行渲染，三维依然参考issue【对vtk python接口做一个封装实现三维绘图】。

个人观点，避免造轮子，优先采用成熟的库。打磨一个算法耗时非常久，我们时间不足。关于造轮子的部分可以写在社区里，目前可以借用CSDN平台后期加外链。

同意以上@心随风的回答。在二维绘图方面，@蒋成龙的PMAGG已经做过很多很多工作，最终目标是将matplotlib封装到平易近人的程度；而对于实时刷新性能问题，我的想法是可以使用pyqtgraph进行。pyqtgraph对于海量点，刷新速度可以非常快。唯一的缺点就是样式不足，难以生成出版质量的图像，但是对于实时刷新的场合，显示是完全够用的。

同意以上@心随风的回答。在二维绘图方面，@蒋成龙的PMAGG已经做过很多很多工作，最终目标是将matplotlib封装到平易近人的程度；而对于实时刷新性能问题，我的想法是可以使用pyqtgraph进行。pyqtgraph对于海量点，刷新速度可以非常快。唯一的缺点就是样式不足，难以生成出版质量的图像，但是对于实时刷新的场合，显示是完全够用的。

@hzy15610046011 同意，二维绘图方面确实是使用matplotlib,对于像@村长这样特殊需求的可以使用pyqtgraph来进行探索。

这里有个pyqtgraph和matplotlib动画的刷新速度比较。相同情况下，pyqtgraph能达到250fps，matplotlib使用blit能到175fps。但是运行里面的matplotlib demo会发现当动画运行时，拖动窗口画面就会出现问题。可能因为改变窗口大小会触发canvas重绘，我之前也遇到过类似情况，所以我暂时在pmagg里面没有用matplotlib的动画类。mpl做动画比较麻烦，还是建议采用更专业的包实现实时刷新。

当然最好能将三维的二维的绘图功能都统一起来，而不是要求用户必须掌握matplotlib,pyqtgraph,vtk这样的各种库。给出一套自己的API接口出来我觉得还是有意义。

Fast Live Plotting in Matplotlib / PyPlot - Stack Overflow

@nihk 请问现在进度如何呢，大佬可以关注一下函数库，在做完线代部分之后绘图应该就是重要任务了，这一部分MATLAB和mpl接口其实类似，但是之前感觉mpl三维很差，MATLAB的surf绘图质量还是很高的。后面可以进一步讨论。

这里有个pyqtgraph和matplotlib动画的刷新速度比较。相同情况下，pyqtgraph能达到250fps，matplotlib使用blit能到175fps。但是运行里面的matplotlib demo会发现当动画运行时，拖动窗口画面就会出现问题。可能因为改变窗口大小会触发canvas重绘，我之前也遇到过类似情况，所以我暂时在pmagg里面没有用matplotlib的动画类。mpl做动画比较麻烦，还是建议采用更专业的包实现实时刷新。
当然最好能将三维的二维的绘图功能都统一起来，而不是要求用户必须掌握matplotlib,pyqtgraph,vtk这样的各种库。给出一套自己的API接口出来我觉得还是有意义。
Fast Live Plotting in Matplotlib / PyPlot - Stack Overflow

@nihk 赞同，在统一二维和三维上做一层封装很有必要，可以使绘图的函数命名的风格趋于一致。

这里有个pyqtgraph和matplotlib动画的刷新速度比较。相同情况下，pyqtgraph能达到250fps，matplotlib使用blit能到175fps。但是运行里面的matplotlib demo会发现当动画运行时，拖动窗口画面就会出现问题。可能因为改变窗口大小会触发canvas重绘，我之前也遇到过类似情况，所以我暂时在pmagg里面没有用matplotlib的动画类。mpl做动画比较麻烦，还是建议采用更专业的包实现实时刷新。

当然最好能将三维的二维的绘图功能都统一起来，而不是要求用户必须掌握matplotlib,pyqtgraph,vtk这样的各种库。给出一套自己的API接口出来我觉得还是有意义。

Fast Live Plotting in Matplotlib / PyPlot - Stack Overflow

@nihk 我尝试了一下，blit的10000个点刷新速度也好快啊。这样一来，感觉pyqtgraph的必要性不是很大了。

import matplotlib.pyplot as plt
import numpy as np

x = np.linspace(0, 2 * np.pi, 100*100)

fig, ax = plt.subplots()

# animated=True tells matplotlib to only draw the artist when we
# explicitly request it
(ln,) = ax.plot(x, np.sin(x), animated=True)

# make sure the window is raised, but the script keeps going
plt.show(block=False)

# stop to admire our empty window axes and ensure it is rendered at
# least once.
#
# We need to fully draw the figure at its final size on the screen
# before we continue on so that :
#  a) we have the correctly sized and drawn background to grab
#  b) we have a cached renderer so that ``ax.draw_artist`` works
# so we spin the event loop to let the backend process any pending operations
plt.pause(0.1)

# get copy of entire figure (everything inside fig.bbox) sans animated artist
bg = fig.canvas.copy_from_bbox(fig.bbox)
# draw the animated artist, this uses a cached renderer
ax.draw_artist(ln)
# show the result to the screen, this pushes the updated RGBA buffer from the
# renderer to the GUI framework so you can see it
fig.canvas.blit(fig.bbox)
import time

for j in range(100):
    t1 = time.time()
    # reset the background back in the canvas state, screen unchanged
    fig.canvas.restore_region(bg)
    # update the artist, neither the canvas state nor the screen have changed
    ln.set_ydata(np.sin(x + (j / 100) * np.pi))
    # re-render the artist, updating the canvas state, but not the screen
    ax.draw_artist(ln)
    # copy the image to the GUI state, but screen might not changed yet
    fig.canvas.blit(fig.bbox)
    # flush any pending GUI events, re-painting the screen if needed
    fig.canvas.flush_events()
    t2 = time.time()
    print(t2-t1)# 0.01左右
    # you can put a pause in if you want to slow things down
    # plt.pause(.1)

在拖动的时候确实会全白一下，但感觉拖动时候的卡顿，还是可以接受的吧。

@nihk 请问现在进度如何呢，大佬可以关注一下函数库，在做完线代部分之后绘图应该就是重要任务了，这一部分MATLAB和mpl接口其实类似，但是之前感觉mpl三维很差，MATLAB的surf绘图质量还是很高的。后面可以进一步讨论。

@心随风 绘图方面函数库封装我可以来做，但我进度可能比较慢，因为现在绘图界面pmagg还有很多不完善的地方，所以这方面仍是花费我多数的时间。

@nihk 我尝试了一下，blit的10000个点刷新速度也好快啊。这样一来，感觉pyqtgraph的必要性不是很大了。

import matplotlib.pyplot as plt
import numpy as np

x = np.linspace(0, 2 * np.pi, 100*100)

fig, ax = plt.subplots()

# animated=True tells matplotlib to only draw the artist when we
# explicitly request it
(ln,) = ax.plot(x, np.sin(x), animated=True)

# make sure the window is raised, but the script keeps going
plt.show(block=False)

# stop to admire our empty window axes and ensure it is rendered at
# least once.
#
# We need to fully draw the figure at its final size on the screen
# before we continue on so that :
#  a) we have the correctly sized and drawn background to grab
#  b) we have a cached renderer so that ``ax.draw_artist`` works
# so we spin the event loop to let the backend process any pending operations
plt.pause(0.1)

# get copy of entire figure (everything inside fig.bbox) sans animated artist
bg = fig.canvas.copy_from_bbox(fig.bbox)
# draw the animated artist, this uses a cached renderer
ax.draw_artist(ln)
# show the result to the screen, this pushes the updated RGBA buffer from the
# renderer to the GUI framework so you can see it
fig.canvas.blit(fig.bbox)
import time

for j in range(100):
    t1 = time.time()
    # reset the background back in the canvas state, screen unchanged
    fig.canvas.restore_region(bg)
    # update the artist, neither the canvas state nor the screen have changed
    ln.set_ydata(np.sin(x + (j / 100) * np.pi))
    # re-render the artist, updating the canvas state, but not the screen
    ax.draw_artist(ln)
    # copy the image to the GUI state, but screen might not changed yet
    fig.canvas.blit(fig.bbox)
    # flush any pending GUI events, re-painting the screen if needed
    fig.canvas.flush_events()
    t2 = time.time()
    print(t2-t1)# 0.01左右
    # you can put a pause in if you want to slow things down
    # plt.pause(.1)

在拖动的时候确实会全白一下，但感觉拖动时候的卡顿，还是可以接受的吧。

@hzy15610046011 mpl和pyqtgraph是完全不同的底层，不容易兼容，建议分开做两个gui插件，构建一套相同的函数库plot(x,y,method='mpl')使用pmagg，plot(x,y,method='graph')使用三维绘图gui，用户按需选择。

@hzy15610046011 mpl和pyqtgraph是完全不同的底层，不容易兼容，建议分开做两个gui插件，构建一套相同的函数库plot(x,y,method='mpl')使用pmagg，plot(x,y,method='graph')使用三维绘图gui，用户按需选择。

@nihk

一个小问题，这个不应该属于method吧，应该是lib或者别的什么名字？backend？

那绘图这边就等大佬封装一下了，这边我确实理解不多很难担此重任

@hzy15610046011 mpl和pyqtgraph是完全不同的底层，不容易兼容，建议分开做两个gui插件，构建一套相同的函数库plot(x,y,method='mpl')使用pmagg，plot(x,y,method='graph')使用三维绘图gui，用户按需选择。

@nihk
按我个人的理解：
1、在静态图（只绘图不刷新，比如老少咸宜的plt.plot）上matplotlib完全可以吊打pyqtgraph（尽管‘吊打’这个词很不专业，但后者至少在生成出版质量图像上远远不足）；
2、在动态图（刷新，比如示波器等场合）上matplotlib相比pyqtgraph在速度上有差距，且由于动态图有实时性，一般不需要精美的样式。
所以我个人的看法就是：统一接口只要留给动态图就行，静态绘图我认为再次封装必要不大，直接用pmagg即可。

先以折线图为例说说我个人之前的理解，应该有以下方法需要在代码中留出接口：
1、绘制线
2、设置线颜色、设置线的数据点颜色、设置线形状、设置点形状
3、设置横纵坐标轴的范围
4、设置横纵轴标签
5、设置标题
6、设置图例文字（位置甚至都不用）
7、清空重绘

对于动态图，还要设置数据停留、重绘策略（比如当数据新增的时候显示窗口是显示最新的几百个点，还是显示全部点）等等。

再说一下我个人对于封装的想法：
如果只是动态刷新时间序列数据，我的建议是封装一个名字类似于PMTimeSeriesShow的控件，专门用来绘制时间序列信号的动态图，具有上面列举的这些方法

至于标题、位置、字体等等，pmagg的功能很强大了，即使代码里就画道线别的都不设置，也可以在图形界面点鼠标。只是pyqtgraph那块估计要做的事情不少。

这里说的留接口给动态图，实际意思就是只封装matplotlib里面快速绘图的部分，不封装pyplot里面只适用于静态图的api（主要是因为这些功能,pyqtgraph里面很可能没有）。

关于绘图，matlab是可以切换绘图引擎的，我想是否能再一次封装，依据matlab的绘图函数进行封装，以句柄形式返回对象，操作句柄时依据不同绘图引擎来调用不同方法。
关于绘图速度上，qt最快的绘图是qwt，我c++用比较多，百万点都是秒级，py也有对它封装但qwt好像已经不维护了。