Making a crowdsourced project on Canvas - page 33
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
In that example, the refresh rate is normal. That's why it doesn't slow down.
In Task Manager I see Metatrader(32 bit)
Has the issue of asynchronous data processing been resolved?May be the reason of your lags have to do with the bit size?
Because Metatrader is now only designed for x64.
And according to developers, 32 bit versions will not be released anymore.
I see Metatrader(32 bit) in Task Manager
And has the issue with asynchronous data processing been resolved?Maybe, the reason of slowness is connected with digit capacity of your system?
Well, Metatrader is now intended for x64 only.
And according to the developers, 32 bit versions will not be released anymore.
I confirm that Nikolai's example I mentioned does load the CPU when moving any of the objects in the example, especially if done quickly. The load increases by 35-40%. The test was conducted on a 64-bit processor, 64-bit Windows 7 and 64-bit MT5.
What is meant by asynchronous processing in our discussion?
I can see Metatrader(32 bit) in Task Manager.
And has the issue with asynchronous data processing been resolved?Maybe, the reason of your lags lies in the bit digit capacity of the system?
In fact, Metatrader is now customized only for x64.
And according to developers, 32 bit versions will not be released anymore.
All these examples are on MT4.
MT5 pulls much more, but in case of incorrect redrawing (e.g. a cup) it also loads the processor (I've checked). The problem is in frequency and area of redrawing, which should be reduced by all means. If you need to redraw a cell, then it's the only cell. Otherwise it's a waste of resources, (if for example a cell needs to be redrawn 10 times per second, then redrawing the whole canvas will "kill" the processor and it will be unrealistic). However, it's already clear.
Let me explain. A table cell has three objects - base, text and icon. If the content of a cell changes, we need to make three loops of the canvas. On the first cycle we redraw the base, on the second cycle - the text, on the third - the icon. It's like we have tripled the area of the cell. If you keep re-drawing the whole kanvas in this vein, you will get a serious slowdown. It is therefore necessary to take into account the number of cycles on the canvas area to be redrawn. You may not see it in simple primitives, but it becomes apparent in complex elements. Some elements comprise 10 objects(an input box with buttons or an output list or a window platform) and it is possible to calculate how many cycles on a kanvas array should be made when repainting them. Fortunately, this redrawing doesn't require high repetition rate.
The issue with asynchronous processing has not been solved. There were some ideas, but no solution has been found yet.
Overall, if we are to create a GUI on canvas, we should make it out of separately redrawable elements. Otherwise, the program will quickly reach the limit and after that the lags on simple operations will be noticeable.
What is meant by asynchronous data processing in our discussion?
Well as I understand it in simple words, asynchronous (resource chasing) or multi-threaded (dedicated resource).
I haven't looked at code of Nikolay's examples but because of absence of asynchrony and multithreading inMetatrader the pixel redrawing code is executed synchronously.
And Petera's output data processing is most likely performed synchronously as well. And in both cases it is likely that all this is still processed in cycles.
This increases the load on the processor. For fast response with less load at a time, data processing and redrawing should be paralleled.
Well, as I understand it in simple words, asynchronous (resource race) or multithreading (dedicated resource).
I haven't looked at code of Nikolay's examples but because of absence of asynchrony and multithreading inMetatrader the pixel redrawing code is executed synchronously.
And Petera's output data processing is most likely performed synchronously as well. And in both cases, all this is likely to be processed in loops.
This increases the load on the processor. For fast response with less load at a time, data processing and redrawing should be paralleled.
Not really)) Let me clarify: I have the engine connect to the user application via a resource. That is, - the user application does its calculations in its thread, and passes the data to the engine (carrying the GUI), which may be on a different graph. This handles parameter events and outputs them to the GUI. In other words, the processing is split into two threads. However, this will not be the case in the constructor I will post. The application will include the engine inside itself and everything will be in one thread. But the load on the processor will be the same. The dependence of the speed on the sequence of functions will simply get higher.
Not really)) Let me clarify: I have the engine connect to the user application via a resource. That is, - the user application does its calculations in its thread, and passes the data to the engine (carrying the GUI), which may be on a different graph. This handles parameter events and outputs them to the GUI. In other words, the processing is split into two threads. However, this will not be the case in the constructor I will post. The application will include the engine inside itself and everything will be in one thread. But the load on the processor will be the same. The dependence of the speed on the sequence of executing functions will simply get higher.
here we go again... promises, announcements, chatter.
even already forgotten - "kernel-engine" was published as a decent software ? or as crap in the form of attachments to the comments
Well as I understand in simple terms, asynchronous(resource race) or multithreading(dedicated resource).
I haven't looked at Nikolai's examples code, but because of absence of asynchrony and multithreading inMetatrader, the pixel redrawing code is executed synchronously.
And Petera's output data processing is most likely performed synchronously as well. And in both cases, all this is likely to be processed in loops.
This increases the load on the processor. For fast response with less load at a time, data processing and redrawing should be paralleled.
All operations in MT are strictly synchronous and this cannot really be changed unless the developers add threads to the application.
It's quite surprising that developers are trying to expand MT functionality in terms of working with databases, with python, with sharpe... but they offer to do it all in the same thread... It's just amazing.
here we go again ... promises, announcements, chatter
I even forgot - was the "kernel-engine" published as a decent software ? or as crap, as attachments to comments
Good for you. I get inspiration from struggling with people like you, and they always lose.)) You're giving me energy and you don't realise it.
here we go again ... promises, announcements, chatter
I even forgot - was the "kernel-engine" published as a decent software ? or as crap in the form of attachments to the comments
Max, be discreet.
Not really)) Let me clarify: I have the engine connect to the user application via a resource. That is, - the user application does its calculations in its thread, and passes the data to the engine (carrying the GUI), which may be on a different graph. This handles parameter events and outputs them to the GUI. In other words, the processing is split into two threads. However, this will not be the case in the constructor I will post. The application will include the engine inside itself and everything will be in one thread. But the load on the processor will be the same. It's just that the dependency of the speed on the sequence of functions will be greater.
I get the point, application separately, GUI separately.
But processing of output data in GUI is performed synchronously anyway.
For example, the application sends 10000 elements to GUI and GUI processes all these elements sequentially.
This is the problem. It is necessary to parallelize processing of incoming elements and their output in GUI. Basis, text, icon.
All the more, there are three cycles per cell.