Making a crowdsourced project on Canvas - page 19

 

.

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.

 
Реter Konow:

.

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 look at the sources? I for myself, for experience .
 
Vladimir Pastushak:
Is it possible to have a look at the source code? For me, for my experience.
Yes, on this page I have posted a block of functions that draw all these windows together. https://www.mql5.com/ru/forum/92113/page16
Делаем краудсорсовый проект по Canvas
Делаем краудсорсовый проект по Canvas
  • www.mql5.com
Приветстсвую кодеров. Есть интересная задача сделать действительно что-то полезное, и думаю что краудсорс будет хорошим вариантом...
 
The problem of delayed reactions has been solved. The solution was as follows:

An image is created once. This is the first time it takes the longest time to draw it, because the image consists of many parts, and drawing each part is a call to the drawing functions, each of which loops over the part and initializes the values in the array.

I'll explain what the problem was:

Before, when drawing the details of an image, I was doing a loop over the entire image area and that's what created the delay. For a 500×500 pixels window, I had to redraw about 300 parts for each repaint, which resulted in (500×500×300×number of drawing functions) interactions in cycles in each repaint. This turns out to take time even for a computer.
The solution was this: instead of re-drawing the image on each event that requires repainting of a particular detail within the image, I draw the image once, and at the next repaints I return it into an array using ResourceReadImage().

Then I redraw the part without looping over the whole image, but I calculate the pixel location of the image part in the image array by a special formula and redraw it only. That way, no unnecessary integration is done. Also, I merged the drawing functions into one, which also made the mechanism more efficient.





 
Is it realistic to speed up rendering in Canvas using OpenCL?
 
Timur Gatin:
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

OpenCL: от наивного кодирования - к более осмысленному
OpenCL: от наивного кодирования - к более осмысленному
  • 2012.06.05
  • Sceptic Philozoff
  • www.mql5.com
В данной статье продемонстрированы некоторые возможности оптимизации, открывающиеся при хотя бы поверхностном учете особенностей "железа", на котором исполняется кернел. Полученные цифры весьма далеки от предельных, но даже они показывают, что при том наборе возможностей, который имеется здесь и сейчас (OpenCL API в реализации разработчиков терминала не позволяет контролировать некоторые важные для оптимизации параметры - - в частности, размер локальной группы), выигрыш в производительности в сравнении с исполнением хостовой программы очень существенен.
 
Igor Volodin:


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).

 
Igor Volodin:

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 English wiki, the formula is more interesting, you can mix two semi-transparent layers. This can make a semi-transparent interface and other niceties.
 
Timur Gatin:
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.