My approach. The core is the engine. - page 123

 
Реter Konow:

...

ZS. It's possible, though, that the processor is being overloaded by redrawing. That is, drawing inside an array of pixels. In other words, constant initialization of the array with values, occurring at high (16ms) timer frequency.

No, redrawing does not load the processor in any way; it takes a few nano- or at most microseconds for it to send a command to the graphics driver. The processor of the video card performs the painting itself, pixel by pixel, while there are usually hundreds of them and they work simultaneously with the processor in parallel. That is, the processor issues the command to the graphics driver: display a circle with the centre in the screen coordinates Xc, Yc and radius R in CopyPut mode. To the processor this is just a function call with parameters passed. It does not go further than this. Such calls it makes no more often than, for example, 2 times per second, otherwise the user simply can not understand anything on the screen, it can not be pulled so often. For a list of open trades, you can imagine that it may take an hour or a day or more.

And the algorithm (google "Bresenham Algorithm", for example) of pixel-by-pixel colouring is executed by the graphics card, and the processor does not linger on it. It also executes very quickly. And... once per call. No reinitialization at 16ms is required, the screen image is kept constant in the video memory until a new change is made at the command of the processor. Not only that, to speed up the visible screen response, the video memory is also kept in two instances, changes are made on the invisible one, and then the video page is switched immediately.

If your approach to screen output still has the "constant initialization of the array" of pixels you describe - you should get rid of it, it's not the case.

 
Реter Konow:

Click to view.

There is something wrong with the data in the Opening Time column in the picture.

 
Vladimir:

No, redrawing does not load the processor in any way; it takes a few nano- or microseconds at most for it to send a command to the graphics driver. The processors of the video card perform the painting itself, pixel by pixel, while there are usually hundreds of them and they work simultaneously with the processor, in parallel. That is, the processor issues the command to the graphics driver: display a circle with the centre in the screen coordinates Xc, Yc and radius R in CopyPut mode. To the processor this is just a function call with parameters passed. It does not go further than this. Such calls it makes no more often than, for example, 2 times per second, otherwise the user simply can not understand anything on the screen, it can not be pulled so often. For a list of open trades, you can imagine that it may take an hour or a day or more.

And the algorithm (google "Bresenham Algorithm", for example) of pixel-by-pixel colouring is executed by the graphics card, and the processor does not linger on it. It also executes very quickly. And... once per call. No reinitialization at 16ms is required, the screen image is kept constant in the video memory until a new change is made at the command of the processor. Not only that, to speed up the visible screen response, the video memory is also kept in two instances, changes are made on the invisible one and then the video page is switched immediately.

If your approach to screen output still has the "permanent array initialization" of pixels that you describe - you should get rid of it, it's not the case.

What a mess...
It's a mishmash of fragmentary knowledge...

In the end, that's not how it works.

 
Vladimir:

No, redrawing does not load the processor in any way; it takes a few nano- or microseconds at most for it to send a command to the graphics driver. The processors of the video card perform the painting itself, pixel by pixel, while there are usually hundreds of them and they work simultaneously with the processor, in parallel. That is, the processor issues the command to the graphics driver: display a circle with the centre in the screen coordinates Xc, Yc and radius R in CopyPut mode. To the processor this is just a function call with parameters passed. It does not go further than this. Such calls it makes no more often than, for example, 2 times per second, otherwise the user simply can not understand anything on the screen, it can not be pulled so often. For a list of open trades, you can imagine that it may take an hour or a day or more.

And the algorithm (google "Bresenham Algorithm", for example) of pixel-by-pixel colouring is executed by the graphics card, and the processor does not linger on it. It also executes very quickly. And... once per call. No reinitialization at 16ms is required, the screen image is kept constant in the video memory until a new change is made at the command of the processor. Not only that, to speed up the visible screen response, the video memory is also kept in duplicate, changes are made on the invisible one, and then the video page is switched immediately.

If your approach to the output still has the "constant initialization of the array" of pixels - you need to get rid of it.

You have an interesting theory, though it doesn't quite fit with the results of my experiments, which I will now post below.

As the test shows, it is the initialisation of the pixel array that loads the CPU the most.

Check the test EA below.

 

I have to admit that I was a little surprised by the test results.

And so, we are talking about constant function calls at a frequency of 16 ms.

It turns out that it is the initialization of the pixel array during drawing that loads the processor the most.

But the strangest thing was that the repeated function call

ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1);

would load the processor by 10 to 15%.

Also, the calls

   ObjectSetString(0,"MT object",OBJPROP_BMPFILE,"::MT object");  

   ObjectSetString(0,"MT object",OBJPROP_TEXT,"QWERTY");

load the processor by the same 10-15%.

At the same time, simultaneous calls of all three functions

ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1);
   
ObjectSetString(0,"MT object",OBJPROP_BMPFILE,"::MT object");  

ObjectSetString(0,"MT object",OBJPROP_TEXT,"QWERTY");

Does not cause load stacking. The load is still 10-15%.

However, if you add constant array reinitialization loop of a million cells to these calls

for(int a1 = 0; a1 < 1000000; a1++)Arr[a1] = MathRand();

then the CPU load rises to 50%.

//-----------------------------------------------------------------------------------------------------------------------------------------------------

The function itself

ResourceCreate("::MT object",Arr,1000000,1,0,0,0,COLOR_FORMAT_XRGB_NOALPHA);

doesn't load the processor.

The function

ResourceReadImage("::MT object",Arr,w,h);

will load from 0 to 5% depending on the size of the Arr[] array.

 

Here is a test advisor. You need to comment on the lines and check the CPU load in the task manager.

Files:
Test_1.mq4  11 kb
 

Here's his code:

//+------------------------------------------------------------------+
//|                                                       Test_1.mq4 |
//|                                                      Peter Konow |
//|                                             https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Peter Konow"
#property link      "https://www.mql5.com"
#property version   "1.00"
#property strict
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
uint Arr[1000000];
//+------------------------------------------------------------------+
int OnInit()
  {
//--- create timer
   EventSetMillisecondTimer(16); 
   //----------------------------------------------------
   //Создаем МТ-объект.
   //----------------------------------------------------
   ObjectCreate(0,"MT object",OBJ_BITMAP_LABEL,0,0,0);
   //----------------------------------------------------
   //Соединяем с файлом.
   //----------------------------------------------------   
   ObjectSetString(0,"MT object",OBJPROP_BMPFILE,"::MT object");
   //----------------------------------------------------
   //Создаем ресурс.
   //----------------------------------------------------
   ResourceCreate("::MT object",Arr,1000000,1,0,0,0,COLOR_FORMAT_XRGB_NOALPHA);   
   //----------------------------------------------------  
//---
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
//| Expert deinitialization function                                 |
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
  {
//--- destroy timer
   EventKillTimer();
   
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {
//---
   
  }
//+------------------------------------------------------------------+
//| Timer function                                                   |
//+------------------------------------------------------------------+
void OnTimer()
  {
//---
   uint w = 0,h = 0;
   string name;
   //----------------------------------------------------
   //Читаем свойство bool.//Нагрузка процессора отсутствует.
   //----------------------------------------------------
   ObjectGetInteger(0,"MT object",OBJPROP_SELECTED);
   //----------------------------------------------------
   
   //----------------------------------------------------
   //Устанавливаем свойство bool.//Нагрузка процессора: 10% - 15%.
   //----------------------------------------------------
   ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1);
   //---------------------------------------------------- 
   
   //---------------------------------------------------- 
   //Перерисовываем изображение в массиве Arr[].
   //Нагрузка процессора зависит от размера массива. 
   //При 10000 ячеек, нагрузки нет, при 1000000 ячеек, - ~35%.
   //---------------------------------------------------- 
   for(int a1 = 0; a1 < 1000000; a1++)Arr[a1] = MathRand();
   //---------------------------------------------------- 
   
   //---------------------------------------------------- 
   //Пересоздаем ресурс.//Нагрузка процессора отсутствует
   //при любом размере массива.
   //----------------------------------------------------
   ResourceCreate("::MT object",Arr,1000000,1,0,0,0,COLOR_FORMAT_XRGB_NOALPHA);   
   //---------------------------------------------------- 
   
   //----------------------------------------------------
   //Читаем ресурс.
   //Нагрузка процессора зависит от размера массива. 
   //При 10000 ячеек, нагрузки нет, при 1000000 ячеек, 
   //Нагрузка "плавает" от 1 до 6%.   
   //----------------------------------------------------
   ResourceReadImage("::MT object",Arr,w,h);     
   //----------------------------------------------------
   
   //----------------------------------------------------
   //Пересоединяем с файлом.//Нагрузка процессора: 10% - 15%
   //----------------------------------------------------   
   ObjectSetString(0,"MT object",OBJPROP_BMPFILE,"::MT object");  
   //----------------------------------------------------
   
   //----------------------------------------------------
   //Устанавливаем описание объекта.//Нагрузка процессора: 10% - 15%
   //---------------------------------------------------- 
   ObjectSetString(0,"MT object",OBJPROP_TEXT,"QWERTY");   
   //----------------------------------------------------
   
   //----------------------------------------------------
   //Читаем описание объекта.//Нагрузка процессора отсутствует.
   //---------------------------------------------------- 
   name = ObjectGetString(0,"MT object",OBJPROP_TEXT);         
  }
//+------------------------------------------------------------------+
 
Andrey Barinov:

There's something wrong with the data in the Opening Time column in the picture.

Yes. I used TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);

I don't know why it's like that.

 
Реter Konow:

I have to admit that I was a little surprised by the test results.

And so, we are talking about constant function calls at a frequency of 16 ms.

It turns out that it is the initialization of the pixel array during drawing that loads the processor the most.

But the strangest thing was that the repeated function call

would load the processor by 10 to 15%.

Also, the calls

load the processor by the same 10-15%.

At the same time, simultaneous calls of all three functions

Does not cause load stacking. The load is still 10-15%.

However, if you add constant array reinitialization loop of a million cells to these calls

then the CPU load rises to 50%.

//-----------------------------------------------------------------------------------------------------------------------------------------------------

The function itself

doesn't load the processor.

The function

loads from 0 to 5%, depending on the size of the Arr[] array.

Retrog Konow:

I must admit that I was a bit surprised by results of the test.

So, we're talking about constant function calls at 16 msec.

It turns out that it is initialization of an array of pixels during drawing that loads the processor most of all.

But the strangest thing was that the repeated function calls

would load the processor by 10 to 15%.

Also, the calls

load the processor by the same 10-15%.

At the same time, simultaneous calls of all three functions

Does not cause load stacking. The load is still 10-15%.

However, if you add constant array reinitialization loop of a million cells to these calls

then the CPU load rises to 50%.

//-----------------------------------------------------------------------------------------------------------------------------------------------------

The function itself

doesn't load the processor.

The function

will load from 0 to 5% depending on the size of the Arr[] array.


Peter, there's a persistent sense that you don't listen to anything you've been told for hundreds of pages.
Reread the thread - there are answers to the question "why so"

 
Реter Konow:

Yes. I used TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);

I don't know why.

Because instead of OrderOpenPrice put OrderOpenTime()

Reason: