Making a crowdsourced project on Canvas - page 31
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
To paraphrase: You will end up with one EA with an interface, even though one part is done by me and the other part is with you. This will not prevent you from putting the two parts together into one EA.
Anyway, that's what we'll do. I'll publish the builder and teach how to design on it here gui. There's no documentation yet, so if you're interested, keep an eye out for the tutorial.
Copy that!
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)
Is it possible to see this example in open source?
It's sad that the project has gone into closed mode (
It hasn't gone anywhere.
Is it possible to see this example in open source?
What don't you understand about kanvas?
1. it reacts to events like all other graphical objects. In other words, you can track mouse coordinates as it moves, react to mouse and keyboardclick events.
2. it can independently change the colour of each pixel.
What else do you need? And then you need some brains and a willingness to waste a lot of time pointlessly.
What don't you understand about working with a kanvas?
1. it reacts to events like all other graphical objects. That is, you can track mouse coordinates as it moves, react to mouse and keyboardclick events.
2. it can independently change the colour of each pixel.
What else do you need? The next thing you need is some brains and a desire to waste a lot of time.
Well kanvas itself does not react to events. And the fact that you can change each pixel is clear.
I was interested in the implementation of a fragmented re-drawing of the canvas.
But it seems that many have settled on full repainting of the canvas even if it only needs to be redrawn in a small part, that is, a single control.
Well, the kanvas itself doesn't react to events. And the fact that you can change every pixel is clear.
I was interested in the implementation of piecemeal redrawing of the canvas.
But it seems that many have settled on full repaint of the canvas even if it only needs to repaint a small part, i.e. one control.
The canvas itself doesn't react to events, but it doesn't exist by itself.
Fragmentary redrawing - it's worth starting to do and will become clearer if there is such a goal. I think there should be an array of controls, each control has defined boundaries. When you need to redraw a control, you have to go through all the controls, see what else falls into this area and only redraw them. At least like this.
The kanvas itself is not reactive, but it does not exist by itself.
Fragmented redrawing - it's worth starting to do and it will become clearer if there is such a goal. I think there should be an array of controls, each control has defined boundaries. When you need to redraw a control, you have to go through all the controls, see what else falls into this area and only redraw them. At least this way.
That's exactly how I built it. Basically I took standard library as a base, because it has very well worked out moments of transferring events and some other things. Anatoly creates grouping for every different class of elements, while in standard one everything is reduced to one basic object.
As a result, WndObject contains the full description of the most common properties of any control (size, location, background colour, border colour, border thickness, text, picture and so on). Besides the same class contains a reference to the parent control. That is, if no parent is specified for the control then it creates its own kanvas object on the graphic, otherwise it is drawn on the parent's kanvas. Depending on its position (standalone, slave) the coordinates of the item location are also calculated. Additionally, the same object has an array which contains the original description of the parent area occupied by the item. The idea itself is the following: if only the element itself changes, then before it is redrawn, the pixel area is filled with the matrix of parent pixels, and only then the new state of the control is applied. this approach does not require repainting the entire canvas every time, because repainting is bypassing all elements in the array, and recursively with nested elements. For rendering and updating a particular control, we suggest two functions: one that draws over the parent (or on a blank canvas) when creating the whole control, and another that updates the display of only the given control. So it goes like this.
So far "lost" in the event model: after which changes which layers need to be redrawn.
Nikolai in his examples shows that in principle it's not necessary to bother storing data of local areas because repaint of the whole canvas works so quickly that there is no need to go down to details, it's enough to always repaint all at once.