Errors, bugs, questions - page 977

 
Renat:
No GDI methods are called.

I mean TextOut. Isn't it system?

I understand about the label, I don't associate it with GDI in any way

 
voix_kas:

The text changes in all (half) of the labels designed to display the value of the indicator, not its description. You can see this when running the script.

Either I don't understand you. Which line exactly are we talking about?

Sorry, I was looking at the wrong place from my mobile phone and made a mistake.

I will run my own tests in the next few hours and post the source code and detailed results.

 
sergeev:

I mean TextOut. Isn't it system?

I understand about the label, I don't associate it with GDI in any way

I thought with GDI it was about tags.

Modification of label parameters is nothing but massively cramming the command stream into a dedicated queue without any real appending of that data to real objects (objects belong to the chart, not MQL5), until the object data is rendered or read back. That is, the real modification of objects is postponed. We have purposely applied such optimization to allow developers to operate with tens of thousands of objects without slowdowns.

That is, when modifying objects actual execution is delayed, which gives a feeling of speed. Well and the whole burden of drawing is carried on the application's interface (graphic) thread. And when rendering, methods of optimization and cutting off visibility limits work, which allows to work normally with 300 000-500 000 objects per chart.

But when working with bitmaps, the entire work is done in MQL5 at once, without any delay, but after that it's done instantly when rendering. And the total "modification + rendering" time of a bitmap is likely to be faster for a given number of objects. Especially since the bitmap is saved between calls and you can only draw what you need instead of rebuilding the entire canvas.

I'll run detailed tests and post the results showing how objects and bitmaps perform in different modes.

 

Posted the results in a separate thread: Performance testing of single text labels and bitmaps on a chart

The author had a serious bug in his bitmap handling script - in reality he used two bitmaps instead of one and constantly copied them into each other, which reduced performance.

 
Renat:

Posted the test results in a separate thread: Performance testing of single text labels and bitmaps on a chart

The author had a serious flaw in his script when working with bitmaps - in reality he used two bitmaps instead of one and constantly copied them into each other, which reduced performance.

So the way to speed up actual output is a flaw? :)

I've already described here earlier the purpose for which the template canvas and the working canvas were introduced.

 

Let's live long.

The MQL5 handbook says datetime type https://www.mql5.com/ru/docs/basis/types/integer/datetime:

"Range of values from 1 January 1970 to 31 December 3000. "

actually the maximum value at 32535244799 is 3001.01.01 07:59:59

Документация по MQL5: Основы языка / Типы данных / Целые типы / Тип datetime
Документация по MQL5: Основы языка / Типы данных / Целые типы / Тип datetime
  • www.mql5.com
Основы языка / Типы данных / Целые типы / Тип datetime - Документация по MQL5
 
The test is performance-based, so it should not be clogged with additional operations.
 

To improve programming purity I would like to ask the public about this.

Suppose there is a flag (bool Flag) declared globally. When certain events/conditions occur, it must be set to a certain value.

The first variant:

if (некое условие) {
  Flag = false;
}

Second option:

if (некое условие) {
  if (Flag) Flag = false;
}

Which option:

1. faster in terms of performance?

2. If I may say so, "more professional"?

It is assumed that this section of code will get control quite often, e.g. every tick.

 
voix_kas:

To improve programming purity I would like to ask the public about this.

Suppose there is a flag (bool Flag) declared globally. When some events/conditions occur, its value must be set.

Of course, the first variant is faster. Fewer instructions and one less comparison/branching.
 
Renat:
Of course, the first option is faster. Fewer instructions, and also one less comparison/branching.
Thank you.