Gallery of UIs written in MQL - page 56

New comment
 
Nikolai Semko #:
No Perth, still too much. Your interface with all the text, shadows, etc. maxes out at 50ms on a weak processor.
Look for the bug.
Run profiling. See which functions eat up 95% of the time.
Maybe you are using ChartGet or XY functions (although you don't have a binding to a chart).
Anyway, run profiling. It'll only take 40 seconds.

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.))

 
Andrey Barinov #:

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.

 
I'll check the rendering speed of a blank green canvas the size of the chart and post it here.
 
Реter Konow #:

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 doesn't take more than a microsecond( one millionth of a second), even if there are thousands of checks.
Look for a bug.
And stop being defensive! Nobody is attacking you, they just want to help you.
I have noticeable lags (>300 ms) begin at 100 thousand objects, and tied to the price-time.
 
Nikolai Semko #:
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.
Look for a bug.
And stop being defensive! Nobody is attacking you, they only want to help you.
I have noticeable lags (>300 ms) start at 100 thousand objects, and tied to price-time.

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.

 
Реter Konow #:

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.


 
Nikolai Semko #:

I thought maybe you've never worked with profiling. You don't work with debugging either.


Not with debug. I can't do it because of the Russian code. I've worked with profiling. But a long time ago. I like to code the old-fashioned way. It's just the way it is.

I'll do it tomorrow. The last few days, I've been working from 6:00 a.m. to 10:00 to 11:00 p.m.. On and off. I'm a little tired.
 
Speed can probably be put on the back burner and optimising for speed isn't something that can be done quickly, for now it's better to improve the functionality.
 
hini #:
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.
Well, it's always nice for a coder to improve speed. And in general, I agree. It's reasonable. Proper prioritisation in development is very important. Especially in such large projects. It was important for me to know how much speed is important for users. So to speak, to get feedback. Speeding up on its own was not part of my initial plans. I just wanted the users not to cringe from lags when looking at the interface. :)

Of course, the functionality of the elements is still my first priority. Engine, elements, bugs. That's the main thing.
1...4950515253545556
New comment