Gallery of UIs written in MQL - page 57

New comment
 
Реter Konow #:

@Nikolai Semko

...and 50ms full screen works for me too. ....

The test is approximate. I measured the speed of opening a window with three canvases of almost equal size (icons window) and got ~70 ms. If you sum up the area of all the canvases (without elements), then just about the area of the laptop screen 17". This does not include the area of the base of the elements and the icons themselves, which were drawn on top of the canvas. So yes, ~50ms to fill the area of a notional full screen with colour. I haven't measured it exactly yet. Why, when the "elephant" is right in the middle of the room? :)

 
I was talking about 50ms as an overloaded and unoptimised interface. 3-10 ms is normal

Do some profiling though. You will make a lot of discoveries in your code.
 
Nikolai Semko #:
I was talking about 50ms as an overloaded and unoptimised interface. 3-10 ms is normal

Do some profiling though. You will make a lot of discoveries in your code.
Nikolai, these are just numbers. You need specifics. Screen size, at least. Then you can make accurate calculations.
 
Drawing on the canvas is an array initialisation. It is easy to find out the maximum speed - the function with the array filling loop will reveal it. The array size should correspond to the sum of pixels of the conditional screen.
 
You're like Stirlitz who didn't want to go to the potato patch.
Do the profiling...
 
Nikolai Semko #:
You're like Stirlitz who didn't want to go to the potato patch.
Do the profiling...
I did. I'll send you a gif.
 


You need an in-depth study of the cycles within the drawing block. Superficial profiling does not give a complete picture. But it is already clear what the point is. I wrote here

. I think I'm not wrong.

(draft version of the drawing block, I use for tests)
 
Реter Konow #:

...

I have an idea how to change the code and speed up rendering by 2 or 3 times. But I'll do it after the main work. ...

I analysed the complexity of the task and the value of the end result.

Conclusion: there is no sense to do it.

It makes no sense to speed up the first drawing. A second and a half to build 15 windows with complex graphics and scroll bars is a normal result. The first drawing can be hidden from the user's eyes by performing it before opening windows. Visually, the windows will appear instantly after a half-trosecond pause. If of course he wants 15 windows to open at once, which is unlikely.

You don't have to draw the back side of the window. There will be a gain of ~20ms. That doesn't sound impressive.

Last week, the main thing was achieved: using saved images on all events except the first build. This is a huge gain in interface speed.

The rest of the lags have to do with redrawing windows when changing focus, or unnecessary calls. Easy fixes. I don't want this major gain to be ignored because of loading time, which is not that important. However, I've shifted my own focus of attention. You should have.

Here, I close the question of the speed of the first rendering, because of its irrelevance and irrelevance for the current development.

Next update on Sunday. I will roll out an engine with a conceptually complete mechanism of software interaction with the user programme.
 
Реter Konow #:
I analysed the complexity of the task and the value of the end result.

The conclusion was that it made no sense.

Creating 15 windows with complex graphics and scrollbars in a second and a half is a normal result. It is possible to draw the first graphic before opening the window so that it is not seen by the user. Visually, the window will appear immediately after a half-second pause. Of course, if the user wants to have 15 windows open at the same time, this is unlikely.

You do not have to draw the back of the window. There will be a gain of ~20ms. That doesn't sound amazing.

Last week, we achieved our main goal: using saved images for all events except the first build. This is a huge speedup for the interface.

The rest of the delays were related to redrawing the window when changing focus or unnecessary calls. This is easy to fix. I don't want to ignore this major improvement because of load times, which are not that important. However, I have shifted my focus. You should have

Here, I ended the first render speed issue because it is not relevant or important to the current development.

The next update is on Sunday. I will present an engine with a conceptually complete mechanism of interaction between the software and the user programme.

Yes, it's most important to get fully functional software out first.

 
hini #:

Yes, it's important to release a full programme first.

I will.
1...505152535455565758596061626364...70
New comment