Errors, bugs, questions - page 976
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
...
It's strange, I have the opposite picture:
I've got this result:
Forum on trading, automated trading systems and strategy testing
Errors, Bugs, Questions
Renat, 2013.04.27 13:32
I'll do the tests too and write up the results.I've completely forgotten that when testing tags, the drawing is completely derived from the MQL5 system and drawn in the interface flow. In MQL5, only label descriptions are modified.
When drawing a bitmap, all drawing is performed within MQL5 and only a very fast single BitBlt remains in the interface flow.
That is, the testing is completely incorrect because marker mapping is not tested at all. The chart refresh is an asynchronous command that only sends a notification to the interface thread to render. As you can see from the screenshot with ChartRedraw costs.
Argb_normalize is better not to use, as it gives extra cost for colour normalization. It's better to paint simple things in pure colour.
The alpha channel has an aesthetic appeal. When text is displayed "transparently" on top of graphics/balls, theobvious conclusion to draw is that there is a separation of uses.
If you just want to display a message/statistics, text label is faster. Inthe case of creating controls (such as buttons) - bitmap, and without options. Then you can fill the whole rectangular area with solid colour, without alpha channel/transparency, without too much frustration.
Removal of ChartRedraw() function from loop is incorrect, because "atomic operation" of text label property change is not handled by video engine of the terminal.
Yep, exactly the same way how work with array is not handled by video engine.
the problem is to find out which works faster - changing a bitmap or changing a label.
creation of bitmap loses - that's for sure.
and the rendering of the chart in both cases is debatable and secondary.
Just think about the results. You can see that 4 seconds per cycle of changing labels ???? is nonsense.
the changes of labels should be checked purely on the change, not interfering with the rendering subsystem of the chart.
otherwise you would see comparable numbers with a bitmap.
I've completely forgotten that when testing tags, the drawing is completely derived from the MQL5 system and drawn in the interface flow. In MQL5, only label descriptions are modified.
When drawing a bitmap, all work is carried out within MQL5.
But the label still changes faster than the bitmap in terms of speed. Because of the slow GDI functions.
In other words, the testing is completely wrong, since mark mapping is not tested at all. The chart refresh is an asynchronous command that only sends a notification to the interface thread to be drawn. Which is what you can see from the screenshot with ChartRedraw costs.
Exactly.
I think we need to test under a few specific heavy tasks. who will take to do a benchmark task like this?
- Drawing a graph (e.g. sine wave) using a bunch of labels (rectangle) and using a bitmap.
- drawing an excel table (rectangle+text label) and as a bitmap.
and other options where MT graphics can be replaced by bitmaps.
check resource consumption to support one bitmap and a lot of MT objects. + dependence on size of areas to be filled.
Another thing you can see from the label test is that there is a very economical one-way write operation with no read labels. In this case there is maximal fast piperization of command flow per write (we purposely use efficient system in this case).
But if you mix up writing with reading object data, which is often the case in real work, then the speed drops dramatically.
Update: Also in markers test example there is critical error - only one modification goes to one marker, not 26. Take a look at the source.
That is, the testing is completely incorrect, as it doesn't test the label mapping at all.
tag changes should be tested purely for changes, without the chart rendering subsystem being swept in.
I, of course, would disagree. Argument: it is desirable for the user to see the situation change (stats) as often as possible, on every tick. Therefore, after updating the stats, they should be shown = ChartRedraw().
This is, so to speak, in terms of the immediate application/practical nature of performance.
As for spherical benchmarks in a vacuum - this is optional.
but the mark still changes faster than the bitmap in terms of speed. Because of the slow GDI functions.
There is also acritical errorin the label test example - only one label is modified, not 26. Look at the source.
The text changes in all (half) of the labels, which are designed to display the value of the indicator, not its description. When you run the script, you can see that.
Either I do not understand you. Which line in particular are we talking about?