You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
How can I limit the kanvas refresh rate in the visualizer in a human way?
So that on slow speed the picture is updated in real time, and on fast speed it doesn't slow down the test?
Right now canvas (if it is updated on every tick) really slows down the whole visualization (profiling shows 80-90% of rendering time). I twisted with configurable pause in seconds, but it's a crutch, limiting functionality (picture updates rarely even at slow speed).
What to bind to so it doesn't refresh too often? GetMicroseconds?
Which functions to skip?
Andrey I already wrote about it here more than a year ago.
It works quite well.
Here's a live video (just two kanvases):
I just need to add that in the tester the CHARTEVENT_CHART_CHANGE event doesn't work,
so I include the following into canvas forming block (when using iCanvas):
And here's part of the code in OnCalculate from the indicator that's on the gif:
it's obvious to the naked eye that kanvas is significantly slower
In the MT5 tester, the timer works, you can set it to 60 sec and it will update once a minute at the tester time)
About the pause crutch I wrote, it doesn't work.
Andrei, I wrote about it here over a year ago.
It works quite well.
Here's a live video (just two kanvases):
Looks a bit slow, as for maximum speed.
Thanks, I'll try via GetTickCount!
Looks a bit slow for maximum speed.
Thanks, I'll try via GetTickCount!
No it's not the maximum. It's very sensitive in front of the maximum.
Here's the maximum:
Looks a bit slow for maximum speed.
Thanks, I'll try using GetTickCount!
Also, so that there is no bias with respect to the chart itself, we should try experimenting with OBJ_BITMAP instead ofOBJ_BITMAP_LABEL. To bind to time and price instead of XY coordinates.
I still want to try it, but I cannot make it. In this case we will have to make the canvas larger than the window size and change the control logic. The code may have a significant speed advantage due to not having to redraw the whole canvas, but only a smaller part of it, if the vertical scale stays the same. In any case, it won't be annoying to see the kanvas unbalanced with the main graph when moving fast.
No it's not the maximum. It's very sensitive in front of the maximum.
That's the maximum:
Is that "all ticks"?! If so, cool. I'll check it.
Also, so that there is no bias in relation to the chart itself, we should try experimenting with OBJ_BITMAP instead ofOBJ_BITMAP_LABEL. To bind to time and price instead of XY coordinates.
I all want to try it, but I cannot make it. In this case we would have to make the canvas larger than the window size and change the control logic. Perhaps there will be a speed gain. Anyway, the unbalanced canvas and the main chart will not be breaking the eye when the motion is fast.
I have a simple panel. No link to the chart.
I have a regular dashboard. There's no link to the chart.
ah, well, that's fine then.
I have one canvas on my hypha too, and it's the panel that eats up the least amount of resources, because I don't have to redraw it as often and catch the moment a new bar comes in.
Is that "all tics"?! If so, cool. I'll check it out.
No it was minute OHLC on 3 minutes. But I checked on all ticks. The picture is almost the same. Because kanvas redrawing in this case is not tied to ticks, but only to actual time(not tester time). I.e. the higher speed is, the lower frame density is. But to the eye the difference is not visible.