이미지는 한 번 생성됩니다. 이미지가 많은 디테일로 구성되어 있고 각 디테일을 그리는 것은 드로잉 함수에 대한 호출이기 때문에 가장 시간이 많이 걸리는 그리기는 처음입니다. 정렬.
문제가 무엇인지 설명하겠습니다.
과거에는 이미지의 세부 사항을 칠할 때 이미지의 전체 영역을 반복했는데 이것이 지연을 만들었습니다. 500 * 500 픽셀의 창 영역을 사용하여 다시 그릴 때마다 약 300개의 이미지 세부 정보를 다시 그려야 했으며 결과는 다시 그릴 때마다 (500 × 500 × 300 × 그리기 기능 수) 반복이었습니다. 결과적으로 이것은 컴퓨터에서도 시간이 걸립니다.
해결책은 이렇습니다. 이미지 내의 특정 세부 사항을 다시 그려야 하는 모든 이벤트에서 이미지를 다시 그리는 대신 이미지를 한 번 그리고 후속 다시 그릴 때 ResourceReadImage() 를 사용하여 배열로 반환합니다.
다음으로, 전체 이미지에 대해 루프를 수행하지 않고 부분을 다시 그립니다. 그러나 특수에 따라 이미지가 있는 배열에서 이미지 부분의 픽셀 위치를 계산합니다. 수식을 만들고 그것만 다시 그립니다. 따라서 불필요한 반복이 수행되지 않습니다. 또한 그리기 기능을 하나로 통합하여 메커니즘을 더 효율적으로 만들었습니다.
В данной статье продемонстрированы некоторые возможности оптимизации, открывающиеся при хотя бы поверхностном учете особенностей "железа", на котором исполняется кернел. Полученные цифры весьма далеки от предельных, но даже они показывают, что при том наборе возможностей, который имеется здесь и сейчас (OpenCL API в реализации разработчиков терминала не позволяет контролировать некоторые важные для оптимизации параметры - - в частности, размер локальной группы), выигрыш в производительности в сравнении с исполнением хостовой программы очень существенен.
그리고 Erase와 함께 OCL의 매복이 있습니다. memset과 유사한 것은 없습니다(CUDA와 달리). 따라서 이제 호스트에서 Erase를 수행하고 CLBufferWrite를 통해 제거된 어레이를 복사해야 합니다. 이는 단순 Erase보다 확실히 빠르지 않습니다. 배열에 1포인트를 쓰는 작업 단위에 대한 작업 배열을 만들려고 했지만 속도가 기억나지 않습니다. 이전 방법보다 느린 것 같았습니다.
그리고 OCL 1.2에는 이 작업을 수행하는 clEnqueueFillBuffer() => MQL 구문은 CLBufferFill() 이어야 합니다.
그리고 Erase와 함께 OCL의 매복이 있습니다. memset과 유사한 것은 없습니다(CUDA와 달리). 따라서 이제 호스트에서 Erase를 수행하고 CLBufferWrite를 통해 제거된 어레이를 복사해야 합니다. 이는 단순 Erase보다 확실히 빠르지 않습니다. 배열에 1포인트를 쓰는 작업 단위에 대한 작업 배열을 만들려고 했지만 속도가 기억나지 않습니다. 이전 방법보다 느린 것 같았습니다.
그리고 OCL 1.2에는 이 작업을 수행하는 clEnqueueFillBuffer() => MQL 구문은 CLBufferFill() 이어야 합니다.
그러나 이 래퍼는 구현되지 않았습니다(버전 1.1이 이식되었기 때문에).
영어 위키에서는 공식이 더 흥미롭습니다. 두 개의 반투명 레이어를 혼합할 수 있습니다. 이것은 반투명한 인터페이스와 다른 아름다움으로 할 수 있습니다.
.
포스팅하기로 약속한 영상입니다. 이미지 품질은 좋지 않지만 반응 지연을 볼 수 있습니다.
실제로 터미널에서 지연이 더 적습니다. 녹음 프로그램을 켜면 모든 것이 두 배 느리게 진행됩니다. 프로세서도 훨씬 더 많이 로드됩니다.
따라서 이 영상에서 반응 속도에 대한 완전히 객관적인 아이디어를 얻는 것은 불가능하지만 창 업데이트 속도와 크기 사이의 패턴은 명확하게 볼 수 있습니다.
(그래서 크기가 다른 창을 여러 개 만들었습니다.)
이미지 반응이 억제된 이유를 정확히 이해한 것 같다. 요점은 ColorToARGB() 함수의 지속적인 호출입니다 . 모든 이벤트와 모든 픽셀에서 이 함수를 호출합니다. 색상을 한 번 계산하고 기성품으로 사용하는 대신 항상 다시 계산합니다.
그것이 요점이라고 생각합니다.
추신: 모든 창의 총 개체 수가 35개라는 것을 추가하는 것을 잊었습니다.
.
포스팅하기로 약속한 영상입니다. 이미지 품질은 좋지 않지만 반응 지연을 볼 수 있습니다.
사실, 터미널에서의 지연은 더 적습니다. 녹음 프로그램을 켜면 모든 것이 두 배 느리게 진행됩니다. 프로세서도 훨씬 더 많이 로드됩니다.
따라서 이 영상에서 반응 속도에 대한 완전히 객관적인 아이디어를 얻는 것은 불가능하지만 창 업데이트 속도와 크기 사이의 패턴은 명확하게 볼 수 있습니다.
(그래서 크기가 다른 창을 여러 개 만들었습니다.)
이미지 반응이 억제된 이유를 정확히 이해한 것 같다. 요점은 ColorToARGB() 함수의 지속적인 호출입니다 . 모든 이벤트와 모든 픽셀에서 이 함수를 호출합니다. 색상을 한 번 계산하고 기성품으로 사용하는 대신 항상 다시 계산합니다.
그것이 요점이라고 생각합니다.
추신: 모든 창의 총 개체 수가 35개라는 것을 추가하는 것을 잊었습니다.
출처만 봐도 가능한가요? 나 자신을 위해, 경험을 위해.
OpenCL로 캔버스 렌더링 속도를 높일 수 있습니까?
네. OCL에는 처리를 병렬화하는 기능 + 벡터에서 작동하는 기능이 있습니다. 이는 그리기/오버레이 프로세스의 속도를 높입니다.
Mathemat의 기사 https://www.mql5.com/en/articles/407에서 벡터 사용에 대한 추가 정보
네. OCL에는 처리를 병렬화하는 기능 + 벡터에서 작동하는 기능이 있습니다. 이는 렌더링/오버레이 프로세스의 속도를 높입니다.
Mathemat의 기사 https://www.mql5.com/ru/articles/407에서 벡터 사용에 대한 추가 정보
CCanvas의 Erase() 속도와 OpenCl에서 만든 PixelSet() 루프를 비교해 보셨습니까? 이론적으로 좋은 가속으로 중간 결과 및 기타 어려움을 캐싱하지 않고도 어리석은 그리기 코드를 만들 수 있습니다.
그건 그렇고, 당신은이 공식에 따라 레이어를 혼합합니까?
예, 각 색상 구성 요소에 대한 wikipedia의 공식: 결과 = 배경 + (전경 - 배경) * 알파;
그리고 Erase와 함께 OCL의 매복이 있습니다. memset과 유사한 것은 없습니다(CUDA와 달리). 따라서 이제 호스트에서 Erase를 수행하고 CLBufferWrite를 통해 제거된 어레이를 복사해야 합니다. 이는 단순 Erase보다 확실히 빠르지 않습니다.
배열에 1포인트를 쓰는 작업 단위에 대한 작업 배열을 만들려고 했지만 속도가 기억나지 않습니다. 이전 방법보다 느린 것 같았습니다.
그리고 OCL 1.2에는 이 작업을 수행하는 clEnqueueFillBuffer() => MQL 구문은 CL Buffer Fill () 이어야 합니다.
그러나 이 래퍼는 구현되지 않았습니다(버전 1.1이 이식되었기 때문에).
예, 각 색상 구성 요소에 대한 wikipedia의 공식: 결과 = 배경 + (전경 - 배경) * 알파;
그리고 Erase와 함께 OCL의 매복이 있습니다. memset과 유사한 것은 없습니다(CUDA와 달리). 따라서 이제 호스트에서 Erase를 수행하고 CLBufferWrite를 통해 제거된 어레이를 복사해야 합니다. 이는 단순 Erase보다 확실히 빠르지 않습니다.
배열에 1포인트를 쓰는 작업 단위에 대한 작업 배열을 만들려고 했지만 속도가 기억나지 않습니다. 이전 방법보다 느린 것 같았습니다.
그리고 OCL 1.2에는 이 작업을 수행하는 clEnqueueFillBuffer() => MQL 구문은 CL Buffer Fill () 이어야 합니다.
그러나 이 래퍼는 구현되지 않았습니다(버전 1.1이 이식되었기 때문에).
영어 위키에서는 공식이 더 흥미롭습니다. 두 개의 반투명 레이어를 혼합할 수 있습니다. 이것은 반투명한 인터페이스와 다른 아름다움으로 할 수 있습니다.
그리고 제 경우에는 이것이 필요하지 않았으며 모든 것이 올바르게 혼합되었습니다. A층 아래의 모든 것은 기판으로 간주될 수 있습니다. 기판 자체가 빛을 발하는 레이어 B가 있더라도 마찬가지입니다.