Making a crowdsourced project on Canvas - page 18
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
Unfortunately, today's attempts to cope with the problem of delayed image updating by saving an array with a "digital mask" have not been successful. However, it is not a failure either. It has simply not been possible to draw a definitive conclusion about the cause of the delay and find a global solution to the problem.
In thinking about the general methods of storing the finished image in memory and working with its areas, I went through various options. The ones I thought were a good solution, but upon deep reflection turned out to be impractical.
And so - my conclusions:
1. If you want to save images in arrays, there should be a lot of arrays. That is, each resource requires its own array of constant memory. In my implementation, the number of canvases (resources, canvases) could be several times greater than the number of windows.
I will explain why:
In some cases this approach is much more convenient than drawing all the window objects on one canvas, e.g. when scrolling a table in a "field of view (VEIW BOX)" element, it's convenient to place table elements on a separate canvas inside this element and scroll this canvas as a whole object. The scrolling speed is faster. So, each such element carries a separate kanvas within it. Otherwise it will have to overwrite the entire image of the window saved in memory. This will definitely take you much longer.
Moreover, it is quite inconvenient to draw all the windows on one canvas, how to move them then? Suppose we create one "mega" canvas for the entire chart area. All our windows will be drawn on it. After drawing the windows on the kanvas, we will try to move them, but to do it we will have to rewrite the entire picture of this single "mega" kanvas. The picture is very big and the amount of rewritten values will be huge. Even if the picture is saved, we will have to overwrite a huge area in memory at each cursor shift. Obviously this is inefficient.
2. Thinking of a method for saving images and working with them, I remembered the "ResourceReadImage()" function. This function reads the resource and puts its numeric mask into an array. So, - there is no need to save the image, because it is already saved at terminal level and can be called up using this function. This greatly simplifies the task. And so: you can fetch the image with "ResourceReadImage()", get it into an array and then change the values of the array, relating to a particular element that is "under the event" of the interface. This approach looks more appealing, in my opinion. However, the question remains - how long will it take to fill the array with an image using "ResourceReadImage()"? Obviously, this also depends on the kanvas area. It may not be visually noticeable at all, but in any case it should be loaded only once while the cursor is located on a particular kanvas area. When moving to another kanvas, you can clear the array and upload the image of the other kanvas.
Anyway, I don't have a final solution right now. I have to try with "ResourceReadImage()" function, measure image loading time and develop system of working with areas of image in the array.
That's all for now.Реter Konow:
In my implementation of the interface, the number of canvases (resources, canvases) can be several times greater than the number of windows. This is required by practice.
Your practice requires it.
But as your own practice shows - this implementation is defective in terms of speed and convenience.
As practice shows, it's more convenient to work with one canvas and there are no obstacles to draw table window temporarily on your canvas and then use BitBlt on the main one.
I don't know why you have planned "there must be many arrays. "But you see yourself that it's a dead-end way.
This is what your practice requires.
But as your own practice shows - such implementation is flawed in terms of speed and convenience.
As practice shows, it's more convenient to work with one canvas and there are no obstacles to draw table window temporarily on your canvas and then use BitBlt on the main one.
I don't know why you have planned "there must be many arrays, moreover - indefinitely many... "But you see yourself that it's a dead-end way.
Perhaps you have found a better solution. I'd love to see it. If you can, post a gif where you can clearly see the response speed of the items on click. I'll post my gif afterwards. You'll see what I'm talking about and I'll see what you're talking about.
I didn't record the video, but I'm sending you an example. It's a quick sketch.
There are 600 drop-down lists.
Move the mouse - with every event and colour change the overall CCanvas is redrawn. You get that interactivity.
You can see the final size in the bitmap properties - 1500x600 px (compared to your 800x500 and 250ms lag). Which equals 900,000 pixels, and all are redrawn instantly. No seconds are out of the question.
Each list is rendered first on its own canvas in its own size (for not to overflow) and then ploughed in on the overall. So we have 600 ResourceCreate calls per mouse event.
This means, as you can see by the reaction speed, that frames are enough to show cartoons.
MT developers gave satisfactory tool without lags (I mean ResourceCreate bitmaps)
I didn't record the video, but I'm sending you an example.
there are 600 drop-down lists.
Move the mouse - with each event and colour change the overall CCanvas is redrawn.
You can see the final size in the bitmap properties - 1500x600 px (compared to your 800x500 and 250ms lag). Which equals 900,000 pixels, and all are redrawn instantly. No seconds are out of the question.
Each list is rendered first on its own canvas in its own size (for not to overflow) and then ploughed in on the overall. So we have 600 ResourceCreate calls per mouse event.
This means, as you can see by the reaction speed, that frames are enough to show cartoons.
MT developers gave satisfactory tool without lags (I mean ResourceCreate bitmaps)
Well, that's good enough to confirm your words... However, I repeat my question from yesterday: is the image saved?
I said yesterday - if you store once created image, change only specific area in it, and send to ResourceCreate() immediately, there will be no delay. Your method of working with canvas is not familiar to me yet. I don't know yet how you have achieved this result.
I have another question: using CCanvas class to create above example, could you describe the principle of implementation of this solution?
Perhaps bitwise operations are used there to process the image. I haven't dealt with them yet.
P.S. However, I like to solve secrets myself...) I will solve this problem anyway.
using CCanvas class to create the above example, can you describe the implementation principle of this solution?
the principle is linear - go through the list of controls and draw each one at a required position on the canvas.
Only CCanvas functions are used for drawing the controls. I didn't draw anything of my own.
e.g., those lists in collapsed form are drawn as two elements - in this example, buttons (this is different in other styles)
the canvas functions are called
FillRectangle // fill background
Rectangle // frame around
FontSet // set font
TextOut // output text
It is possible that bitwise operations are used there to process the image.
no.
is the image saved?
yes, in the array which is in CCanvas
if you store an image once created, change only a specific area in it, and send it immediately to ResourceCreate(), there will be no delay.
not quite right.
In my example the whole array is redrawn. The array is cleared and the whole canvas is filled again on each redraw. Then ResourceCreate is called.
In my example, the whole array is redrawn. The array is cleared and the whole canvas is filled again on each redraw. Then ResourceCreate is called.
Thanks for the elaborate answer.
Strangely, it's the same for me. The image of the entire window is fully recreated at each interface event. It is built in a local one-dimensional array, which is sent to ResourceCreate after this procedure completes.
I don't know why it's slowing me down... Tomorrow I'll post a gif where I'll show the correlation between window size and item response speed.
This is all very strange...
Thanks for the detailed reply.
Strangely, it's the same for me. The image of the entire window is fully recreated at each interface event. It is built in a local one-dimensional array, which is sent to ResourceCreate after this procedure completes.
I don't know why it's slowing me down... Tomorrow I'll post a gif where I'll show the dependency between window size and item response speed.
This is all very strange...
If it's not difficult, make a gif animation with CPU load in task manager. Or it's easier to post the compiled file, assergeev did. So one can test it himself.
OK, I'll make a video of the CPU load. But about the compiled file - I won't post it yet.
Just very ashamed of bugs...))
When I fix them, I promise to post them.
OK, I'll make a video of the CPU load. But about the compiled file - I won't post it yet.
Just very ashamed of bugs...)))
When I fix them - I promise to post.