그것이 바로 내가 만든 방법입니다. 원칙적으로 나는 이벤트 전송의 순간과 다른 몇 가지 포인트가 잘 작동하기 때문에 표준 라이브러리 를 기본으로 사용했습니다. Anatoly는 요소의 서로 다른 각 클래스에 대한 그룹화를 생성하지만 표준 요소에서는 모든 것이 단일 기본 개체로 축소됩니다.
...
Nikolai는 그의 예에서 원칙적으로 로컬 영역 데이터를 저장하는 데 신경쓰지 않아야 함을 보여줍니다. 전체 캔버스를 다시 그리는 작업이 너무 빨라서 아래로 내려갈 필요가 없고 세부 사항이 필요하지 않기 때문에 항상 모든 것을 한 번에 다시 그리는 것으로 충분하기 때문입니다.
그렇게 간단하지 않습니다. 셀 중 하나가 초당 20번 값을 변경하는 큰(전체 그래프에 대해) 테이블을 그렸다고 상상해 보십시오. 전체 캔버스를 다시 그리면 프로세서 부하가 40% 이상으로 증가합니다. 캔버스와 절대적으로 잘못된 작업입니다. 개별 요소를 다시 그려야 합니다. 그렇지 않으면 테이블, 유리 및 다양한 로컬 애니메이션이 프로세서에 과부하가 걸리고 다른 기능의 실행 속도가 느려집니다(공통 스레드에 있는 경우).
Реter Konow : 그렇게 간단하지 않습니다. 셀 중 하나가 초당 20번 값을 변경하는 큰(전체 그래프에 대해) 테이블을 그렸다고 상상해 보십시오. 전체 캔버스를 다시 그리면 프로세서 부하가 40% 이상으로 증가합니다. 캔버스와 절대적으로 잘못된 작업입니다. 개별 요소를 다시 그려야 합니다. 그렇지 않으면 테이블, 유리 및 다양한 로컬 애니메이션이 프로세서에 과부하가 걸리고 다른 기능의 실행 속도가 느려집니다(공통 스레드에 있는 경우).
지금까지 Nikolai의 실험은 그 반대임을 증명합니다. 한 번에 캔버스의 전체 내용을 다시 그리고 이는 코드에서 명확하게 볼 수 있습니다.
그러나 나는 여전히 지역 변화의 지지자입니다. 그러나 이 접근 방식에는 아직 해결하지 못한 특정 어려움이 있습니다.
지금까지 Nikolai의 실험은 그 반대임을 증명합니다. 한 번에 캔버스의 전체 내용을 다시 그리고 이는 코드에서 명확하게 볼 수 있습니다.
그러나 나는 여전히 지역 변화의 지지자입니다. 그러나 이 접근 방식에는 아직 해결하지 못한 특정 어려움이 있습니다.
나는 Nikolay를 내 친구라고 생각하고 그는 캔버스 작업에서 큰 성취를 이루었지만 여전히 컨트롤에 대한 본격적인 실험을 수행하지 않았습니다. 특히 테이블과 유리가 있습니다. 어쨌든, 나는 그들에 대해 모른다.
결론은 다음과 같습니다. Canvas는 데이터 배열입니다. 데이터가 변경되고 변경 이벤트에 다시 저장됩니다. 배열에 그래프 공간의 모든 픽셀이 포함된 경우 크기 는 그래프의 높이*너비입니다 . 어레이 내부의 픽셀 값에 로컬 변경이 있는 경우 전체 어레이를 통해 전체 주기를 수행하고 모든 값을 재설정할 필요가 없습니다. 변경된 영역을 반복하고 값을 설정하고 루프를 종료해야 합니다. 그렇지 않으면 무슨 말을 해도 자원과 시간의 낭비입니다.
그리고 이 접근 방식에는 많은 어려움이 있습니다. 가장 중요한 것은 본격적인 개체를 만들고 캔버스에서 찾아 처리하는 것입니다. 일반 CCanvas는 이에 적합하지 않습니다. 요소를 "볼" 수 없으며 요소를 통해 액세스할 수 없습니다. 그런 기능이 없습니다.
나는 Nikolay를 내 친구라고 생각하고 그는 캔버스 작업에서 큰 성취를 이루었지만 여전히 컨트롤에 대한 본격적인 실험을 수행하지 않았습니다. 특히 테이블과 유리가 있습니다. 어쨌든, 나는 그들에 대해 모른다.
결론은 다음과 같습니다. Canvas는 데이터 배열입니다. 데이터가 변경되고 변경 이벤트에 다시 저장됩니다. 배열에 그래프 공간의 모든 픽셀이 포함된 경우 크기 는 그래프의 높이*너비입니다 . 어레이 내부의 픽셀 값에 로컬 변경이 있는 경우 전체 어레이를 통해 전체 주기를 수행하고 모든 값을 재설정할 필요가 없습니다. 변경된 영역을 반복하고 값을 설정하고 루프를 종료해야 합니다. 그렇지 않으면 무슨 말을 해도 자원과 시간의 낭비입니다.
그리고 이 접근 방식에는 많은 어려움이 있습니다. 가장 중요한 것은 본격적인 개체를 만들고 캔버스에서 찾아 처리하는 것입니다. 일반 CCanvas는 이에 적합하지 않습니다. 요소를 "볼" 수 없으며 요소를 통해 액세스할 수 없습니다. 그런 기능이 없습니다.
나는 이 모든 것을 완벽하게 이해하고 이해합니다. 나는 내 자신의 객체 클래스를 만들었고 모두 훌륭하게 작동합니다.
Nikolay의 애니메이션은 일반적으로 새로 고침 빈도가 낮기 때문에 전체 캔버스를 동시에 다시 그려도 오버레이가 되지 않습니다. 그러나 빈도를 초당 5회로 늘리면 프로세서 리소스 사용량이 증가하는 것을 확인할 수 있습니다. 전체 애니메이션을 다시 그려야 하는 경우 탈출구가 없지만 내부에 별도의 작은 영역이 있는 경우에만 더 좋습니다.
주파수 자체 - 초당 5회, 값이 비동기적으로 변경되는 테이블에서 발생할 수 있습니다. 리소스를 통해 테스터에 테이블을 연결했을 때 MT4에서 이러한 상황이 발생했습니다. 31의 속도로 모든 매개변수가 너무 빨리 변경되어 테이블을 잘못 다시 그리면 프로세서 로드가 50% 이상으로 이어집니다. 요소의 로컬 다시 그리기조차도 완전히 저장되지 않았습니다. 값을 도출하는 속도를 늦추자는 아이디어를 생각해 냈습니다. 값 자체는 자연스러운 속도로 변경되었지만 셀에 표시되는 빈도는 몇 배는 적었습니다. 이것은 문제를 해결했습니다.
다음은 예입니다. 1000개의 셀은 25ms의 빈도로 값을 변경해야 합니다. 실제로 셀은 약 500ms마다 한 번씩 값을 변경하며 프로세서 로드는 약 50%입니다. (이것은 MT4이며 표가 그려져 있습니다).
Реter Konow : 그렇게 간단하지 않습니다. 셀 중 하나가 초당 20번 값을 변경하는 큰(전체 그래프에 대해) 테이블을 그렸다고 상상해 보십시오. 전체 캔버스를 다시 그리면 프로세서 부하가 40% 이상으로 증가합니다. 캔버스와 절대적으로 잘못된 작업입니다. 개별 요소를 다시 그려야 합니다. 그렇지 않으면 테이블, 유리 및 다양한 로컬 애니메이션이 프로세서에 과부하가 걸리고 다른 기능의 실행 속도가 느려집니다(공통 스레드에 있는 경우).
나는 당신이 그 숫자를 어디서 얻었는지 잘 이해하지 못합니다. Nikolai https://www.mql5.com/en/forum/227736/page44#comment_13445909의 완전히 간단한 예를 보십시오. 그래프 크기의 캔버스에서 여러 개체가 생성되어 그래프 주위(캔버스에서)를 끌 수 있습니다. 이것은 전체 캔버스를 다시 그립니다. 브레이크가 없습니다.
나는 당신이 그 숫자를 어디서 얻었는지 잘 이해하지 못합니다. Nikolay의 완전히 간단한 예를 참조하십시오. https://www.mql5.com/en/forum/227736/page44#comment_13445909. 그래프 크기의 캔버스에는 그래프(캔버스에서) 주위로 드래그할 수 있는 여러 개체가 생성됩니다. 이것은 전체 캔버스를 다시 그립니다. 브레이크가 없습니다.
나는 당신이 그 숫자를 어디서 얻었는지 잘 이해하지 못합니다. Nikolay https://www.mql5.com/en/forum/227736/page44#comment_13445909의 완전히 간단한 예를 보십시오. 그래프 크기의 캔버스에서 여러 개체가 생성되어 그래프 주위(캔버스에서)를 끌 수 있습니다. 이것은 전체 캔버스를 다시 그립니다. 브레이크가 없습니다.
그것이 바로 내가 만든 방법입니다. 원칙적으로 나는 이벤트 전송의 순간과 다른 몇 가지 포인트가 잘 작동하기 때문에 표준 라이브러리 를 기본으로 사용했습니다. Anatoly는 요소의 서로 다른 각 클래스에 대한 그룹화를 생성하지만 표준 요소에서는 모든 것이 단일 기본 개체로 축소됩니다.
...
Nikolai는 그의 예에서 원칙적으로 로컬 영역 데이터를 저장하는 데 신경쓰지 않아야 함을 보여줍니다. 전체 캔버스를 다시 그리는 작업이 너무 빨라서 아래로 내려갈 필요가 없고 세부 사항이 필요하지 않기 때문에 항상 모든 것을 한 번에 다시 그리는 것으로 충분하기 때문입니다.그렇게 간단하지 않습니다. 셀 중 하나가 초당 20번 값을 변경하는 큰(전체 그래프에 대해) 테이블을 그렸다고 상상해 보십시오. 전체 캔버스를 다시 그리면 프로세서 부하가 40% 이상으로 증가합니다. 캔버스와 절대적으로 잘못된 작업입니다. 개별 요소를 다시 그려야 합니다. 그렇지 않으면 테이블, 유리 및 다양한 로컬 애니메이션이 프로세서에 과부하가 걸리고 다른 기능의 실행 속도가 느려집니다(공통 스레드에 있는 경우).
지금까지 Nikolai의 실험은 그 반대임을 증명합니다. 한 번에 캔버스의 전체 내용을 다시 그리고 이는 코드에서 명확하게 볼 수 있습니다.
그러나 나는 여전히 지역 변화의 지지자입니다. 그러나 이 접근 방식에는 아직 해결하지 못한 특정 어려움이 있습니다.
지금까지 Nikolai의 실험은 그 반대임을 증명합니다. 한 번에 캔버스의 전체 내용을 다시 그리고 이는 코드에서 명확하게 볼 수 있습니다.
그러나 나는 여전히 지역 변화의 지지자입니다. 그러나 이 접근 방식에는 아직 해결하지 못한 특정 어려움이 있습니다.
나는 Nikolay를 내 친구라고 생각하고 그는 캔버스 작업에서 큰 성취를 이루었지만 여전히 컨트롤에 대한 본격적인 실험을 수행하지 않았습니다. 특히 테이블과 유리가 있습니다. 어쨌든, 나는 그들에 대해 모른다.
결론은 다음과 같습니다. Canvas는 데이터 배열입니다. 데이터가 변경되고 변경 이벤트에 다시 저장됩니다. 배열에 그래프 공간의 모든 픽셀이 포함된 경우 크기 는 그래프의 높이*너비입니다 . 어레이 내부의 픽셀 값에 로컬 변경이 있는 경우 전체 어레이를 통해 전체 주기를 수행하고 모든 값을 재설정할 필요가 없습니다. 변경된 영역을 반복하고 값을 설정하고 루프를 종료해야 합니다. 그렇지 않으면 무슨 말을 해도 자원과 시간의 낭비입니다.
그리고 이 접근 방식에는 많은 어려움이 있습니다. 가장 중요한 것은 본격적인 개체를 만들고 캔버스에서 찾아 처리하는 것입니다. 일반 CCanvas는 이에 적합하지 않습니다. 요소를 "볼" 수 없으며 요소를 통해 액세스할 수 없습니다. 그런 기능이 없습니다.
나는 Nikolay를 내 친구라고 생각하고 그는 캔버스 작업에서 큰 성취를 이루었지만 여전히 컨트롤에 대한 본격적인 실험을 수행하지 않았습니다. 특히 테이블과 유리가 있습니다. 어쨌든, 나는 그들에 대해 모른다.
결론은 다음과 같습니다. Canvas는 데이터 배열입니다. 데이터가 변경되고 변경 이벤트에 다시 저장됩니다. 배열에 그래프 공간의 모든 픽셀이 포함된 경우 크기 는 그래프의 높이*너비입니다 . 어레이 내부의 픽셀 값에 로컬 변경이 있는 경우 전체 어레이를 통해 전체 주기를 수행하고 모든 값을 재설정할 필요가 없습니다. 변경된 영역을 반복하고 값을 설정하고 루프를 종료해야 합니다. 그렇지 않으면 무슨 말을 해도 자원과 시간의 낭비입니다.
그리고 이 접근 방식에는 많은 어려움이 있습니다. 가장 중요한 것은 본격적인 개체를 만들고 캔버스에서 찾아 처리하는 것입니다. 일반 CCanvas는 이에 적합하지 않습니다. 요소를 "볼" 수 없으며 요소를 통해 액세스할 수 없습니다. 그런 기능이 없습니다.
나는 이 모든 것을 완벽하게 이해하고 이해합니다. 나는 내 자신의 객체 클래스를 만들었고 모두 훌륭하게 작동합니다.
나는 이 모든 것을 완벽하게 이해하고 이해합니다. 나는 내 자신의 객체 클래스를 만들었고 모두 훌륭하게 작동합니다.
이 경우 로컬(각 셀 개별)과 전체 테이블의 두 가지 방법으로 테이블을 생성 하고 업데이트하여 확인할 수 있습니다.
Nikolay의 애니메이션은 일반적으로 새로 고침 빈도가 낮기 때문에 전체 캔버스를 동시에 다시 그려도 오버레이가 되지 않습니다. 그러나 빈도를 초당 5회로 늘리면 프로세서 리소스 사용량이 증가하는 것을 확인할 수 있습니다. 전체 애니메이션을 다시 그려야 하는 경우 탈출구가 없지만 내부에 별도의 작은 영역이 있는 경우에만 더 좋습니다.
주파수 자체 - 초당 5회, 값이 비동기적으로 변경되는 테이블에서 발생할 수 있습니다. 리소스를 통해 테스터에 테이블을 연결했을 때 MT4에서 이러한 상황이 발생했습니다. 31의 속도로 모든 매개변수가 너무 빨리 변경되어 테이블을 잘못 다시 그리면 프로세서 로드가 50% 이상으로 이어집니다. 요소의 로컬 다시 그리기조차도 완전히 저장되지 않았습니다. 값을 도출하는 속도를 늦추자는 아이디어를 생각해 냈습니다. 값 자체는 자연스러운 속도로 변경되었지만 셀에 표시되는 빈도는 몇 배는 적었습니다. 이것은 문제를 해결했습니다.
다음은 예입니다. 1000개의 셀은 25ms의 빈도로 값을 변경해야 합니다. 실제로 셀은 약 500ms마다 한 번씩 값을 변경하며 프로세서 로드는 약 50%입니다. (이것은 MT4이며 표가 그려져 있습니다).
https://www.mql5.com/ru/forum/293630/page160
다음은 테스터가 있는 예입니다. 테이블이 그려지지만 프로세서가 과부하로부터 보호되지는 않습니다. :) (테스터 속도 31, 셀 업데이트가 완료되었습니다(출력 건너뛰기 없이)).
https://www.mql5.com/ru/forum/293630/page148
그렇게 간단하지 않습니다. 셀 중 하나가 초당 20번 값을 변경하는 큰(전체 그래프에 대해) 테이블을 그렸다고 상상해 보십시오. 전체 캔버스를 다시 그리면 프로세서 부하가 40% 이상으로 증가합니다. 캔버스와 절대적으로 잘못된 작업입니다. 개별 요소를 다시 그려야 합니다. 그렇지 않으면 테이블, 유리 및 다양한 로컬 애니메이션이 프로세서에 과부하가 걸리고 다른 기능의 실행 속도가 느려집니다(공통 스레드에 있는 경우).
나는 당신이 그 숫자를 어디서 얻었는지 잘 이해하지 못합니다. Nikolai https://www.mql5.com/en/forum/227736/page44#comment_13445909의 완전히 간단한 예를 보십시오. 그래프 크기의 캔버스에서 여러 개체가 생성되어 그래프 주위(캔버스에서)를 끌 수 있습니다. 이것은 전체 캔버스를 다시 그립니다. 브레이크가 없습니다.
나는 당신이 그 숫자를 어디서 얻었는지 잘 이해하지 못합니다. Nikolay의 완전히 간단한 예를 참조하십시오. https://www.mql5.com/en/forum/227736/page44#comment_13445909. 그래프 크기의 캔버스에는 그래프(캔버스에서) 주위로 드래그할 수 있는 여러 개체가 생성됩니다. 이것은 전체 캔버스를 다시 그립니다. 브레이크가 없습니다.
위의 예를 참조하십시오.
gif 링크를 삽입했습니다.다음은 셀에 대한 값 출력을 늦추고 프로세서의 부하를 줄이는 예입니다.
https://www.mql5.com/ru/forum/293630/page148
나는 당신이 그 숫자를 어디서 얻었는지 잘 이해하지 못합니다. Nikolay https://www.mql5.com/en/forum/227736/page44#comment_13445909의 완전히 간단한 예를 보십시오. 그래프 크기의 캔버스에서 여러 개체가 생성되어 그래프 주위(캔버스에서)를 끌 수 있습니다. 이것은 전체 캔버스를 다시 그립니다. 브레이크가 없습니다.
이 예에서는 일반적인 재생 빈도입니다. 그래서 느려지지 않습니다.