Canvas vs Labels - page 8
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
Yeah, didn't see that it was an internal chart.
Well judging by the profiling, the source of the brakes, when scrolling the chart, is in this line:
Profiling with active scrolling:
Profiling with active mouse movement without scrolling(without the LKM pressed):
ZS: So the source of the brakes is not the kanvas after all, but the objects.
Unfortunately, my profiling of this code gives out a blank. b2828.
Unfortunately, my profiling of this code gives out a blank. b2828.
It looks like they haven't finished the profiler yet. I used to get a blank sometimes too. But now it works.
It works with this one too.
This is the wrong approach. Especially since the visual tester has a different delayed rendering model, so as not to completely slow down the testing process.
I see. So,in addition to measuring in the tester, you'll have to measure in the chart.
I didn't say that.
I pointed out the obvious errors and explained how the rendering system works.
Well then I got it all wrong. Sorry.
It looks like they haven't finished the profiler yet. I used to get a blank sometimes too. But now it works.
this one works too.
I got nothing on b2830 too.
with the Windows event model - even if you move the mouse quickly, the CPU load starts to increase, no matter what application was in focus
SZY: Checked it in task manager in Win10... Not showing any increase in CPU load for some reason, in Win7 exactly the same load was increasing if I moved the mouse quickly - I doubt Win10 have drastically changed the event model, most likely the task manager works in a different way
Vin10. Here's the plot when I move the mouse in the input window of this text message with the LKM held down
Here's without the LKM
Vin10. Here is the plot when I move the mouse in the input window of this text message with the LKM pressed
Here's without the LKM.
not obvious
Here's the virtual desktop with Win7 - if I don't move the mouse, it loads the CPU 3-4%
if mouse is moving fast - 11-14% load
I mean that message queue in Win always needs to be processed, but it's extra CPU cycles - google "C++ windows window" - any manual for writing windows windows application in C++ using WinAPI, read there about message handler
not illustrative.
from a virtual machine under Win7 - if you don't move the mouse, 3-4% CPU load
if mouse is moving fast - 11-14% CPU load
I mean that message queue in Win always needs to be processed and it takes extra CPU cycles - google "c++ windows window".
To put it in numbers more clearly, I'm not doing anything - 10-15 fluctuates, 17-30 when moving.
But should this cause OnTimer to slow down by 2 times, no of course, unless at 95-99% load.
Any manual on writing Windows window application in C++ using WinAPI, read there about message handler
But should it cause OnTimer to slow down twofold, no, of course, except for 95-99% load.
timer is also a WinAPI event, but I doubt that every MQL-program subscribes to the system timer - it emulates the MQL environment(virtual machine)
message handler takes CPU share and so on, just not used when there is no queue. For MT processes there should be no CPU time cutoff at this load.
There is always a queue at an active window. It's a common coffee-leaf guess how this queue is distributed by the terminal between charts and then between MQL-programs.
well, in the end - to get a monopoly mode and not to process messages - not many options, the first that comes - exclusive full-screen mode application, but that's another story, as if the "battle for resources PC", then you just need an API to go to the exchange and write your application, and there register the window or not
ok, not interested in looking for peak CPU load - as long as we're in Vin, anything can happen, I'm generally fine with it
timer is also a WinAPI event, but I doubt that every MQL program subscribes to the system timer - it emulates the MQL environment(virtual machine)
not a fact. if you remember there was a bug with timer and number of handlers in the terminal, it indirectly suggests that each timer in MT may well be a system wineplay