
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
.
Here's the video I promised to publish. The picture quality is poor, but it doesn't prevent you from seeing the response delays.
In fact, there is less delay in the terminal. When the recorder is on, everything is twice as slow. The processor loads much more, too.
So, it is not possible to get a completely objective idea of the reaction speed from this video, but it clearly shows a pattern between window refresh rate and window size.
(That's why I made several windows of different sizes.)
I think I've got the exact reason for the image response slowdown. It is the constant call of the ColorToARGB() function. At every event and at every pixel I call this function. Instead of calculating colours once and using them ready, I recalculate them all the time.
I think this is the point.
P.S. I forgot to add that the total number of objects of all windows is 35.
.
Here's the video I promised to publish. The picture quality is poor, but it doesn't prevent you from seeing the response delays.
In fact, there is less delay in the terminal. When the recorder is on, everything is twice as slow. The processor loads much more, too.
Therefore, it is not possible to get a completely objective idea of the reaction speed from this video, but I can clearly see a pattern between window refresh rate and window size.
(That's why I made several windows of different sizes.)
I think I've got the exact reason for the image response slowdown. It is the constant call of the ColorToARGB() function. At every event and at every pixel I call this function. Instead of calculating colours once and using them ready, I recalculate them all the time.
I think that's the point.
P.S. I forgot to add that the total number of objects of all windows is 35.
Is it possible to have a look at the source code? For me, for my experience.
Is it realistic to speed up rendering in Canvas with OpenCL?
Yes. OCL has the ability to parallelize processing + the ability to operate on vectors - this speeds up the rendering/overlaying process.
Read more about using vectors in Mathemat's article https://www.mql5.com/ru/articles/407
Yes. OCL has a possibility to parallelize processing + possibility to operate with vectors - this speeds up the drawing/layering process.
Read more about using vectors in Mathemat's article https://www.mql5.com/ru/articles/407
Have you compared the speed of Erase() from CCanvas and the PixelSet() loop made in OpenCl? In theory, with a good speedup, you can make dumb drawing code without caching intermediate results and other complications.
By the way, do you mix layers using this formula?
Yes, the formula is from wikipedia, for each colour component: Result = Background + (Foreground - Background) * Alpha;
By the way, there is a problem with Erase in OCL. There is no analogue of memset (unlike CUDA). This is why I now have to do Erase in the host and copy the cleaned up array via CLBufferWrite, which certainly isn't faster than simple Erase.
On the other hand, I tried making a task array for work units writing 1 point into the array but cannot remember the speed - it seemed to be slower than the previous method.
And in OCL 1.2 there isclEnqueueFillBuffer() that does that => according to MQL syntax there should be CLBufferFill()
But this wrapper is not implemented (as version 1.1 is ported).
Yes, the formula is from wikipedia, for each colour component: Result = Background + (Foreground - Background) * Alpha;
By the way, there is a problem with Erase in OCL. There is no analogue of memset (unlike CUDA). This is why I now have to do Erase in the host and copy the cleaned up array via CLBufferWrite, which certainly isn't faster than simple Erase.
On the other hand, I tried making a task array for work units writing 1 point into the array but cannot remember the speed - it seemed to be slower than the previous method.
And in OCL 1.2 there isclEnqueueFillBuffer() that does that => according to MQL syntax there should be CLBufferFill()
But this wrapper is not implemented (as version 1.1 is ported).
In the English vic, the formula is more interesting, you can mix two translucent layers. It's possible to make a translucent interface and other pretty things.
I didn't need this in my case, everything blends correctly. Anything below layer A can be considered the substrate, even if layer B is on top of it, through which the substrate itself shines through.