Gallery of UIs written in MQL - page 56
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
No Perth, still too much. Your interface with all the text, shadows, etc. maxes out at 50ms on a weak processor.
Yeah, I'll check everything again. But that's not the point. The drawing block doesn't just draw. There are logical mazes inside it that process incoming events. They are needed to determine what to draw and what not to draw. Choose where to take images from, where and how to overlay them. If it were a simple drawing function of 100 lines, there would be nothing to say. But this is a massive mechanism to ensure that EVERYTHING is drawn.
That's worth taking into consideration.))
I am just NOT using the stock canvas :).
...
And this, is a pleasant surprise. :) Self-development is always cool. Even if it is imperfect.
I don't mind the Ccanvas class (even included its functionality in the constructor files), but I don't use it yet. The key word is "yet." I have big plans for it. In the future.
Yeah, I'll double-check everything. But that's not the point. The drawing block does not only draw. There are logical labyrinths inside it that process incoming events. They are needed to determine what to draw and what not to draw. Choose where to take images from, where and how to overlay them. If it were a simple drawing function of 100 lines, there would be nothing to say. But this is a massive mechanism to ensure that EVERYTHING is drawn.
That's worth taking into consideration.))
No, when implemented correctly, the event model does not take more than a microsecond (one millionth of a second), even if there are thousands of checks.
I'm not being defensive))) Ha ha. Just explaining. ))
Okay. I'll start with a simple test. I'll fill one full screen canvas with one colour and measure the time. You make measurements of your rendering function and then it will become clearer whether I have brakes in my code. Maybe there are. I'm not arguing. I need to check it.
I'm not being defensive.) Ha ha. Just explaining. ))
Okay. I'll start with a simple test. I will fill one full screen canvas with one colour and measure the time. You make measurements of your rendering function and then it will become clearer whether I have brakes in my code. Maybe there are. I'm not arguing. I need to check it.
I thought that maybe you have never worked with profiling. You don't work with debugging either.
I thought maybe you've never worked with profiling. You don't work with debugging either.
Speed can probably be relegated to the background, and optimising for speed is not something that can be done quickly, it's better to improve functionality for now.
@Nikolai Semko
Nikolai, now unexpectedly came the answer to the question"why it takes so long to draw a canvas".
The windows consist of two canvases! These canvases are almost equal in size. So the drawing area should be multiplied by two. But that's just the beginning.
On the window space there are large scrolling elements (V_BOX), which are also drawn completely filled with the original colour. That is, if V_BOX occupies the main part of the window, the drawing area should be multiplied by three. But! it has an additional canvas. The image is scrolled on that canvas. The base of the element is only a scroll bar. In short - the drawing area should be multiplied by four (especially if the scroll bar is long). And only then, the elements are drawn.
It would seem to be all... We can put a point. We multiply the area of the window by three or four. But no!
Theelements themselves are also multi-layered. Each has a base. The base is always drawn from scratch, filled with the original colour. Then the frames are drawn on top of the base. Next, icons are drawn on top of the already drawn parts of the element. And finally, texts are drawn on top of everything.
As a result, the user sees only the final colour on each particular pixel. But at the place of this pixel the colours changed several times as the whole window is drawn.
Now multiply this by 15 windows.... It becomes clear that there is no special bug in the code - I have specially measured the speed of execution of parts of the drawing block, and 50 ms for a full screen works for me too. It's just that I end up with a lot more screens.
I have an idea how to change the code and speed up drawing by 2 or 3 times. But I will do it after the main work.
I want to thank you for insisting on checking the code. You were right. That's the case when criticism was helpful.
Also, thanks to @AndreyBarinov for the hint with the text. Maybe I can come up with something.