Discussion of article "Graphical Interfaces X: The Standard Chart Control (build 4)" - page 3
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
You are wrong. I've already answered in enough detail in the comments above why it was done this way.
Now it doesn't consume a lot of resources (now in Windows 10 too). Did you read the article (and the comments too) ?
//---
P.S. By the way, CPU resource consumption in different terminals (MT4/MT5) and OS versions (Windows) is very different under equal conditions. In Windows 7 the MetaTrader 4 terminal showed itself significantly better than MetaTrader 5. Unfortunately, I can't give you the figures now, as I have already completely switched to Windows 10.
As for optimisation, I have not exhausted all the options yet. There is still something to optimise and I understand how.
To implement accelerated scrolling of something and to smoothly change the colour of an object under the cursor, a timer is necessary. Everything is correct here.
But it cannot cause resource consumption up to 10 per cent in the idle state. So the problem lies elsewhere. What is it?
That is, at each timer event, you check the events of all interface elements? Why?
What is there in this checking that can load the processor?
For example, moving the mouse cursor in the area of a clean chart, when there is nothing on it at all (graphical objects and MQL-applications) already raises the CPU consumption up to 6-7%:
Before the test:
During the test:
To implement accelerated scrolling of something, and to smoothly change the colour of the object under the cursor, a timer is necessary. Everything is correct here.
But it cannot cause resource consumption up to 10 per cent in the idle state. So the problem lies elsewhere. What is it?
That is, at each timer event, you check the events of all interface elements? Why?
Now it is implemented so that only at the moment of moving the cursor. And this is only in Windows 10. In Windows 7 this was not the case.
And if you use the method you suggested, then the same costs will be spent on preparing an array with the elements over which the cursor is now located + some other problems come out. I've already tested this method and gave up on it, as there is no actual gain there.
There are some other options, but they still need to be tested. If there is a gain, it will be presented in one of the next articles.
For example, moving the mouse cursor in the area of a clean chart, when there is nothing on it at all (graphical objects and MQL-applications) already raises the CPU consumption up to 6-7%:
Before the test:
During the test:
Unfortunately, this fact cannot be optimised.
However, checking the states of control elements on timer events (in my opinion, too frequent. Instead of 16 ms. you can put 25 ms. ) should not increase resource consumption in any way, if no resource-consuming action is performed during this check.
...
What is it about this test that can strain the processor?
...
However, checking the states of control elements at timer events (I think it is too frequent. Instead of 16 ms. you can set 25 ms. ) should not increase resource consumption in any way,
if no resource-consuming action is performed during this check.
Now it is implemented so that only at the moment of moving the cursor. This is only in Windows 10. In Windows 7, this was not the case.
And if you use the method you suggested, then the same costs will be spent on preparing an array with the elements over which the cursor is now located + some other problems come out. I've already tested this method and gave up on it, as there is no actual gain there.
There are some other options, but they still need to be tested. If there is a gain, it will be presented in one of the next articles.
1. And here, you are already wrong. Preparing the map array with coordinates and sizes of elements, as well as adjusting their values on the events of moving windows, does not significantly increase the load on the processor, because the work is done only on the event of moving the cursor and only when grasping the handle of the window. In case of any other cursor movements, the function of coordinates recalculation will not be called.
2. When simply moving the cursor, the localiser function will be called, which will loop through the map of elements and find the object under the cursor. This process is purely computational and does not load the processor.
Реter Konow:
Preparing a map array with coordinates and sizes of elements, as well as correcting their values on window movement events, does not significantly increase the load on the processor, since the work is done only on the cursor movement event and only when grabbing the window handle.
That's why there is no sense in it. The goal is not to increase the load on the processor, even if it is insignificant, but on the contrary, to reduce it. It turns out that I am not mistaken. )
Redrawing the chart to show changes.
Why redraw the whole chart when changes can be made point by point, in relation to a specific element?
You can check the necessity of changes every 16ms, (checking does not load), but apply the change to each specific object only when necessary and not redraw the whole chart.
Why redraw the whole chart when changes can be made point by point, in relation to a specific element?
After each change on the chart, you need to call the ChartRedraw() function for instant display. The same applies to drawing on the canvas. Therefore, changes are first made on all elements and only then, once, is the chart redrawn.
Konow tag:
You can check the necessity of changes every 16ms, (checking does not load), but apply the change to each specific object only when necessary and do not redraw the entire chart.
Right now nothing is redrawn every 16ms at rest at all. It's not like the user will be cutting circles with the mouse cursor on the graph without stopping. In the current implementation, CPU resource consumption does not exceed 6-7%.
After each change on the chart, you must call the ChartRedraw() function for instant display. The same applies to drawing on the canvas. That's why changes are first made on all elements and only then, once, the chart is redrawn.
This is very, very strange. I don't have a single call to the ChartRedraw() function in my implementation of the interface.
I didn't really know why it was needed until now..... I work with canvas (bitmap objects) without it.
Let's assume that ChartRedraw() function is necessary, - then it turns out that every change of each object requires complete redrawing of all objects?