这是一个有趣的话题。但这种方法有一些缺点。如果图形数字是 "画了就忘",那么在移动图表、更改 TF 等操作时,mt5 会自行缩放它们,那么在任何 CHARTEVENT_CHART_CHANGE 时,Canvas 都应始终重新绘制,即使 VP 位于历史中的某处,也应在已更改的数据上重新绘制。必须获取这些数据,但这些数据(tick 数据)并不总是在 mt5 缓存中,要么存储在内存中并检查 VP 边界是否发生变化,要么不断向 mt5 请求(现在我已经这样实现了),但这并不能快速奏效,因此数据并不总是完整提供,也不能立即确定。
绘图是问题的一部分。第二部分是,交易者并不总是只需要一张图片来欣赏它,他还需要基于这张图片的信号,如 POC、VHL、VLL、"进入空档 "等。而且我们只能将事件绑定到图形对象上(有条件的情况下,我们可以将它们保存在指标中的某个数组中,但还是希望能直观地看到这个级别在哪里,警报是在哪里触发的)。也就是说,我们仍然需要图形对象来显示 kanvas VP,当然,与通过图形对象显示 VP 的情况相比,图形对象的数量要少一个数量级甚至几个数量级。
总的来说,总结如下--我们无法从 mt5 中获得体积终端(目前还不能)(我们需要簇、三角洲等)。
图中是 VP 在脉冲波上的示例,POC 用线表示,这里是 tick volume,如果有真实的 volume,我会对其进行处理(finam、amp global)。比较高级 TF 上的刻度线交易量和实际交易量的实践表明,它们要么重合,要么非常接近,除了大交易量穿过高位或低位蜡烛图的情况,在这种情况下,刻度线交易量对我们毫无帮助。
这是一个有趣的话题。但这种方法有一些缺点。如果图形数字是 "画了就忘",那么在移动图表、更改 TF 等操作时,mt5 会自行缩放它们,那么在任何 CHARTEVENT_CHART_CHANGE 时,Canvas 都应始终重新绘制,即使 VP 位于历史中的某处,也应在已更改的数据上重新绘制。必须获取这些数据,但这些数据(刻度线数据)并不总是在 mt5 缓存中,要么存储在内存中并检查 VP 边界是否发生变化,要么不断向 mt5 请求(现在我已经这样做了),但这并不能快速奏效,而且数据并不总是完整提供,也不能立即确定。
绘图是问题的一部分。第二部分是,交易者并不总是只需要一张图片来欣赏它,他还需要基于这张图片的信号,如 POC、VHL、VLL、"进入虚空 "等。而且我们只能将事件绑定到图形对象上(有条件的情况下,我们可以将事件保存在指标中的某个数组中,但最好还是能直观地看到这个级别在哪里,警报是在哪里触发的)。也就是说,我们仍然需要图形对象来显示画布上的 VP,当然,与通过图形对象显示 VP 的情况相比,图形对象的数量要少一个数量级甚至几个数量级。
总的来说,总结如下:我们无法从 mt5 中获得体积终端(目前还不能)(我们需要群集、三角洲等)。
这张图是 VP 在脉冲波上的示例,POC 用一条线表示,这里是 tick volume,如果有真实的 volume,我会对其进行处理(finam、amp global)。比较高级 TF 上的刻度线交易量和实际交易量的实践表明,它们要么重合,要么非常接近,除了大交易量穿过高位或低位蜡烛图的情况,在这种情况下,刻度线交易量对我们毫无帮助。
不完全是这样。这些并不是缺点,而是您需要了解的功能,以便以最大的可能性和自由度使用该工具。
一切都可以完成,即使是 3D 群集。
以下是仅使用 Canvas 而未使用 OpenCL 的MQL5 示例。如果使用 OpenCL(即显卡),速度将大幅提升(数十倍)。


新文章 市场轮廓指标 (第二部分):基于画布的优化与渲染已发布:
在上一篇文章中,我们深入探讨了市场轮廓指标。事实证明,使用普通的图形对象来构建市场轮廓图会消耗相当多的资源。对于从K线低点到高点的每个价格点,都会用矩形图形对象来填充,其数量等于当天内达到该价格水平的K线数量。每个轮廓图都是如此——它们都包含大量的图形对象,并且所有这些对象都会在绘制轮廓图的每一天被创建和绘制。当一个指标创建了成千上万个图形对象时,这可能会导致在处理其他图形对象和重绘图表时出现严重的性能下降。
对于三个交易日,市场轮廓最终将如下所示:
作者:Artyom Trishkin