Gallery of UIs written in MQL - page 53
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
Rether, would you consider changing the catalogue to English in future releases? The source code files containing the catalogue names are replaced with text.
Yes, of course. Already thought about it. I will make a special release version with catalogue names in English.
I'm not checking the files only the comments here. But that 'lag' for me seems to not be related to speed, but with the use of ChartRedraw before completely create the new resource. Because it blincks with a blank canvas an then show the new canvas.
Sure. I've given it some thought. I'll make a special release that includes the English catalogue name.
I would suggest not to make a special release with English catalogues, but to make only one such English release, just changing the name of the catalogue to English, and the next step would be to change the file name to English, and you will still write the source code in Russian.
I agree. I will gradually switch to English names of directories. It will be more rational that way.
I haven't checked the files, just the comments here. But this "lag" for me doesn't seem to be related to speed, but to using ChartRedraw before the new resource is fully created. Because it flashes a blank canvas and then shows the new canvas.
Interesting idea, I'll try to test it out. Thanks.
And so, an update...
This is an interim update. I will release the next version in a few days. There will be new functionality for programme interaction with controls.
I have to say this: I work on two builds - 2470 and the new one. Most of the development is done on the old build. Compilation is faster there - 4 seconds vs. 26-32 seconds. The new build works a bit differently and it is visually noticeable. Sometimes it is faster, sometimes slower. Maybe it just feels that way. It's hard to find a difference, but to me it seems to be there. The interface on the old build flies. On the new one. almost flies. Maybe I think it's because I'm used to it.
However, there are nuances. For example, there is a problem with switching charts, when incorrect values of chart height and width are returned. This makes the taskbar jump. I managed to bypass this problem, but then the taskbar does not react to other events of chart resizing. In the end - decided to leave it as it was. Taskbar will jump on chart switching (as long as there is a problem of returning incorrect values), but it will adapt normally on other events.
But that's not all. It turns out that events of chart resizing do not come instantly and there is a pause of half a second. This delay is superimposed on the time of redrawing the taskbar and you get a decent lag. Here I am powerless.
I'll say this: of course, I have significantly accelerated graphics, but there are still some other unoptimised solutions in the code. I am working hard on them. Mostly it concerns window focus transition and redraw queue. Some unnecessary calls happen. Taskbar lags. I fixed what I had time to fix, though not everything. But the rest is a matter of the next few days. Otherwise, there is nothing much to improve... maybe only to comb and perfume the code to make it fragrant)).
In general, if we debug all the remaining non-optimised solutions - it will fly... well, within the speeds available to an MQL-programme, of course.
Take the release.
And so, an update...
...
Let me put it this way: the graphics of course significantly accelerated, but there are still some other unoptimised solutions in the code. I am working hard on them. Mostly it concerns window focus transition and redraw queue. Some unnecessary calls happen. Taskbar lags. I fixed what I had time to fix, though not everything. But the rest is a matter of the next few days. Otherwise, there is nothing much to improve... maybe just comb and perfume the code to make it fragrant)).
In general, if we debug all the remaining unoptimised solutions - it will fly... well, within the speeds available to an MQL-programme, of course.
Take the release.
Let me make it clear: we are talking about speed here. If you fix the flaws of window redrawing on the focus change event, the interface speed will be at the upper limit of an MQL-program. Lags of the taskbar can be partially fixed. I came up with a good solution - to apply in the mechanics of the taskbar the principle of a dynamic window - it does not slow down when resizing, when it is pulled by the frame. It will adjust faster and more imperceptibly. And of course, we need to cancel unnecessary redraws. This is mandatory. But if the CHARTEVENT_CHART_CHANGE events themselves come to the programme with a delay, the visible lag of the taskbar reactions is inevitable, though it has nothing to do with it.
Otherwise, there are many directions of interface development and improvement.
A few more words about the interface speed.
I have spent a lot of time checking delays and searching for rendering brakes. The block responsible for kanvas layout is built in such a way that before initialising the array that goes to create a resource in the ResourceCreate() function, it defines the boundaries of the loop on the window details. It does this with the help of condition-filters configured to check incoming events. Each event calling the block is given drawing boundaries. For example, on the event of the element reaction to the cursor hovering, the filter with the loop boundaries only on the details of a particular element is enabled. The block selects only its details on the taken image. And during the cycle on details, it selectively draws only them among the rest of the image. It accurately finds the places to initialise and draw the correct detail of the correct element. At the same time, it correctly bypasses the rest of the image space.
But the acceleration is not only that. The block does not initialise the points of the canvas if their colour matches the required value. Also, it does not "run" through the array, but "jumps", stepping over distances. This reduces cycles by hundreds of thousands of iterations.
Not only that. Since the image array is global (declared at the global level), it always stores the change of the last image in its memory. And if changes continue to occur on the same canvas, instead of clearing its array each time, the stored image is used. If the resource name doesn't change on the next event, then there is no need to call ResourceReadImage(), and no need to send the canvas array again to be filled. The block continues to work with the remaining data without calling ResourceReadImage(), and updates the image with ResourceCreate() after the change.
This saves a lot of time on ResourceReadImage() calls. And also on clearing and filling the array. It's a good use of global memory, isn't it?
When redrawing windows, the block is not called at all. Window components are erased and created and previously saved resources are attached to them. There is no rendering.
With all this, there are still lags, and they are inevitable. Let me explain what is going on.
At the first opening of a window, or at the first opening of a tab, or at the event of a tree list, or at minimising/unmodelling large spaces, there is a mandatory full redrawing of canvases. Up to the moment of creating image resources that can be efficiently linked/changed many times later, ONE time ALWAYS you need to draw a complete image from scratch. The first drawing is ALWAYS the longest. There is nothing to save, there is no saved image. It is when you first open it that you can always see lags. It is inevitable.
However, there is a good solution here too: move the lags of opening windows to the loading event. What I mean: at the stage of loading the constructor in the background draw all the images and save them in resources in advance, so that everything would be ready when opening. Then the user will not see any delays when opening windows for the first time. This is great of course, but there is a downside. The lag of the first opening will turn into a lag of loading and its time will increase. It's hard to say how much. I think, on average, within a second. Depends on the specific interface.
I think this option is preferable. I'd rather let the designer/user interface load a little longer, but there will be no more visual opening lags.
Interested to hear your opinions on this.
Added:
There was an idea to save interface resources after the first load to a file. Then subsequent loads will be much faster, because the necessary resources are already at the disposal of the designer/engine. Need to think about it.