My approach. The core is the engine. - page 123
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
...
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.
Click to view.
There is something wrong with the data in the Opening Time column in the picture.
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.
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
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.
Here is a test advisor. You need to comment on the lines and check the CPU load in the task manager.
Here's his code:
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.
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.
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"
Yes. I used TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);
I don't know why.
Because instead of OrderOpenPrice put OrderOpenTime()