작업 차트에서 직접 확인하는 것이 더 좋은데 왜 전략 테스터(및 시각적 지연 디스플레이의 특수 버전에서도)에서 그래픽 구성 을 테스트해야 합니까?
동시에 로봇에서 비시각적 테스터에서 그래픽 구성을 끄는 것을 생각하지 않는 사람들을 축하합니다.
차트에서도 확인할 수 있습니다. 그러나 테스터에서 이것을 하는 것이 더 쉬울 것이라고 생각했습니다. 게다가 위에서 언급한 것처럼 씨캔바스 기반으로 디스플레이를 만들어 테스터에서 EA의 작업이 많이 느려지는 상황이 있었습니다. 이것은 특히 진드기에 해당되었습니다. 차트에서 이것을 보여주기 위해 텍스트의 출력은 루프에서 수행되어야 합니다. 즉, 현재 작업 중인 오프라인 최적화로 내 EA에서 수행되는 것처럼 더 높은 빈도로 업데이트를 수행합니다. 그리고 Canvas를 사용하면 속도가 느려지기 때문에 레이블 기반 디스플레이를 만들기로 결정했습니다. 알다시피 레이블은 다른 스레드에서 그려지므로 내 루프에서 수행되는 전문가의 자동 최적화 속도가 느려지지 않습니다.
당신이 말했듯이 OBJ_BITMAP_LABEL을 렌더링하는 것보다 레이블의 텍스트를 렌더링하는 데 더 많은 시간이 걸립니다. 그런 다음 속도에서 이기려면 렌더링도 별도의 스레드에서 수행해야 합니다. 하지만 어떻게? 할 수 없다면 그런 다음 다음을 사용 하는 응용 프로그램 의 관점에서 밝혀졌습니다. OBJ_LABEL 이OBJ_BITMAP_LABEL 보다 빠릅니까?...
그리고 Canvas를 사용하면 속도가 느려지기 때문에 레이블 기반 디스플레이를 만들기로 결정했습니다.
캔버스 속도가 느려진 이유가 거의 확실합니다. 여러 프레임을 하나의 30밀리초 프레임에 넣으려고 했기 때문입니다. 사실 프레임은 초당 약 30프레임보다 더 자주 다시 그려지지 않습니다(ChartRedraw).
여기에서 말했듯이 텍스트 캔버스와 레이블의 차이점은 레이블의 경우 픽셀 배열 채우기가 비동기적으로 발생하고 사용자가 제어하지 않기 때문에 레이블의 경우 픽셀 배열 채우기가 수행되지 않는다는 것입니다. 약 30밀리초마다 한 번 이상 발생합니다. 그리고 캔버스의 경우 이 프로세스(비트맵 채우기)가 비동기식이 아니기 때문에 이러한 일이 발생할 수 있습니다. 그리고 30밀리초 안에 비트맵을 10번 채울 수 있으며, 한 번만 표시되고 9번은 작업이 유휴 상태였습니다. 따라서 Canvas 주제에서 이미 논의한 것처럼 - 멋지네요! , 프로그래머는 BitMap 채우기 시작 시간을 제어해야 합니다. 행동 모델은 다음과 같을 수 있습니다.
비트맵을 생성하는 함수가 하나 있습니다.
이 함수의 입력에서 이미지 형성의 시작 시간은 밀리초 단위의 정적 변수에 저장됩니다.
다음에 이 기능을 입력할 때 마지막 Bitmap 형성이 시작된 후 30밀리초 미만이 지났는지 확인해야 합니다. 그렇다면 종료하고 false를 반환하고, 그렇지 않은 경우 새 비트맵을 채우고 표시합니다.
물론 bool 변수를 클래스에 도입하여 캔버스의 형성을 허용하거나 금지하는 것이 더 편리합니다.
캔버스 속도가 느려진 이유가 거의 확실합니다. 여러 프레임을 하나의 30밀리초 프레임에 넣으려고 했기 때문입니다. 사실 프레임은 초당 약 30프레임보다 더 자주 다시 그려지지 않습니다(ChartRedraw).
여기에서 말했듯이 텍스트 캔버스와 레이블의 차이점은 레이블의 경우 픽셀 배열 채우기가 비동기적으로 발생하고 사용자가 제어하지 않기 때문에 레이블의 경우 픽셀 배열 채우기가 수행되지 않는다는 것입니다. 약 30밀리초마다 한 번 이상 발생합니다. 그리고 캔버스의 경우 이 프로세스(비트맵 채우기)가 비동기식이 아니기 때문에 이러한 일이 발생할 수 있습니다. 그리고 30밀리초 안에 비트맵을 10번 채울 수 있으며, 한 번만 표시되고 9번은 작업이 유휴 상태였습니다. 따라서 Canvas 주제에서 이미 논의한 것처럼 - 멋지네요! , 프로그래머는 BitMap의 채우기 시간을 제어해야 합니다. 행동 모델은 다음과 같을 수 있습니다.
비트맵을 생성하는 함수가 하나 있습니다.
이 함수의 입력에서 이미지 형성의 시작 시간은 밀리초 단위의 정적 변수에 저장됩니다.
다음에 이 기능을 입력할 때 마지막 Bitmap 형성이 시작된 후 30밀리초 미만이 지났는지 확인해야 합니다. 그렇다면 종료하고 false를 반환하고, 그렇지 않은 경우 새 비트맵을 채우고 표시합니다.
캔버스의 형성을 허용하는 변수를 클래스에 도입하는 것이 아마도 더 나을 것입니다.
이것에 대해 더 읽을 수 있는 곳이 있습니까? 나는 모든 것을 이해하지만 여전히 주제가 매우 흥미 롭습니다! 이제 비트맵 업데이트를 제어하는 변형을 만들고 테스트해야 합니다. 비트맵이 레이블보다 빠르면 놀랄 것입니다.
여기 내가 말하는 내용을 보여주는 예가 있습니다. 여기 문서에서 스크립트의 기초를 가져왔습니다. 여기서, 처음에는 100번 출력하도록 random array를 구성하고, 각각 100줄씩, 100 Label을 구성한다. 먼저 Label이 있는 100개의 프레임이 표시됩니다. 그런 다음 캔버스 라인이 있는 100개의 프레임. 캔버스 하나. 슬립 루프가 문서화되어 있습니다. 루프에 Sleep(0)이 있으면 완전히 다른 그림이 됩니다. 실험할 수 있습니다. 모든 프레임과 라인은 제어를 위해 번호가 매겨집니다. 동영상을 녹화하고 속도를 30번 늦췄습니다. 이를 통해 100개 중 2개의 프레임만 레이블에 대해 실제로 표시되었음을 알 수 있으며 두 번째 프레임에서는 다른 프레임의 레이블 즉, 비동기 작업이 보입니다.
따라서 Label에 대한 이러한 값은 가짜입니다. 캔버스는 100개 중 60-70개 정도의 프레임에 표시됩니다. 이는 프레임이 30밀리초보다 약간 빠르게 형성되므로 모든 프레임이 형성되지만 모든 프레임이 표시될 시간이 없기 때문에 발생합니다. 상위 2개 옵션으로 실험 주기가 지연됩니다.
출력 행의 수를 늘리면 오류 4001을 잡을 수 있습니다. 이것은 개체가 너무 많을 때 MQ 결함입니다.
작업 차트에서 직접 확인하는 것이 더 좋은데 왜 전략 테스터(및 시각적 지연 디스플레이의 특수 버전에서도)에서 그래픽 구성 을 테스트해야 합니까?
동시에 로봇에서 비시각적 테스터에서 그래픽 구성을 끄는 것을 생각하지 않는 사람들을 축하합니다.
Nikolai의 말이 맞습니다. 레이블 속성 편집은 레이블 렌더링과 관련이 없습니다.
차트의 다른 개체와 마찬가지로 레이블은 MQL5 프로그램의 작동과 관계없이 완전히 다른 스레드에서 그려집니다. 로봇은 차트에 강제로 다시 그리도록 요청할 수만 있지만 그리는 시간은 측정할 수 없습니다. 개체로 차트를 그리는 것은 완전히 비동기식입니다.
그러나 캔버스에 그리는 것은 로봇 스레드에서 직접 수행되기 때문에 측정하기 쉽고 차트를 독립적으로 그리는 동안 완성된 비트맵의 기본 BitBlit을 창 컨텍스트로 만드는 작업이 남아 있습니다. 이 작업은 기본적이며 비디오 카드에 의해 잘 가속화됩니다.
텍스트 레이블에서 TTF 글꼴의 SetFont/TextOut은 상당히 비쌉니다.이 측정에 따르면 321번이라는 것이 밝혀졌습니다.
작업 차트에서 직접 확인하는 것이 더 좋은데 왜 전략 테스터(및 시각적 지연 디스플레이의 특수 버전에서도)에서 그래픽 구성 을 테스트해야 합니까?
동시에 로봇에서 비시각적 테스터에서 그래픽 구성을 끄는 것을 생각하지 않는 사람들을 축하합니다.
차트에서도 확인할 수 있습니다. 그러나 테스터에서 이것을 하는 것이 더 쉬울 것이라고 생각했습니다. 게다가 위에서 언급한 것처럼 씨캔바스 기반으로 디스플레이를 만들어 테스터에서 EA의 작업이 많이 느려지는 상황이 있었습니다. 이것은 특히 진드기에 해당되었습니다. 차트에서 이것을 보여주기 위해 텍스트의 출력은 루프에서 수행되어야 합니다. 즉, 현재 작업 중인 오프라인 최적화로 내 EA에서 수행되는 것처럼 더 높은 빈도로 업데이트를 수행합니다. 그리고 Canvas를 사용하면 속도가 느려지기 때문에 레이블 기반 디스플레이를 만들기로 결정했습니다. 알다시피 레이블은 다른 스레드에서 그려지므로 내 루프에서 수행되는 전문가의 자동 최적화 속도가 느려지지 않습니다.
당신이 말했듯이 OBJ_BITMAP_LABEL을 렌더링하는 것보다 레이블의 텍스트를 렌더링하는 데 더 많은 시간이 걸립니다. 그런 다음 속도에서 이기려면 렌더링도 별도의 스레드에서 수행해야 합니다. 하지만 어떻게? 할 수 없다면 그런 다음 다음을 사용 하는 응용 프로그램 의 관점에서 밝혀졌습니다. OBJ_LABEL 이 OBJ_BITMAP_LABEL 보다 빠릅니까?...
이것은 자세히 연구했거나 알고 있는 숙련된 프로그래머에게 자명합니다. 철저한 터미널 운영! 그리고 저는 터미널 개발자가 아니라 응용 프로그램만 작성하기 때문에 대부분의 프로그래머와 마찬가지로 MQL 문서에 없는 내용을 모를 수 있습니다.
이것은 자세히 연구했거나 알고 있는 숙련된 프로그래머에게 자명합니다. 철저한 터미널 운영! 그리고 저는 터미널 개발자 가 아니라 응용 프로그램만 작성하기 때문에 대부분의 프로그래머와 마찬가지로 MQL 문서에 없는 내용을 모를 수 있습니다.
그럼에도 불구하고 당신은 개발자뿐만 아니라 MQ 회사의 이사와 논쟁하려고합니다.
그럼에도 불구하고 당신은 개발자뿐만 아니라 MQ 회사의 이사와 논쟁하려고합니다.
나는 논쟁하려는 것이 아니라 그것을 사용하는 애플리케이션의 관점에서 OBJ_BITMAP_LABEL이 OBJ_LABEL 보다 저렴하게 만들어질 수 있는지 알아보기 위해!
그리고 Canvas를 사용하면 속도가 느려지기 때문에 레이블 기반 디스플레이를 만들기로 결정했습니다.
캔버스 속도가 느려진 이유가 거의 확실합니다.
여러 프레임을 하나의 30밀리초 프레임에 넣으려고 했기 때문입니다.
사실 프레임은 초당 약 30프레임보다 더 자주 다시 그려지지 않습니다(ChartRedraw).
여기에서 말했듯이 텍스트 캔버스와 레이블의 차이점은 레이블의 경우 픽셀 배열 채우기가 비동기적으로 발생하고 사용자가 제어하지 않기 때문에 레이블의 경우 픽셀 배열 채우기가 수행되지 않는다는 것입니다. 약 30밀리초마다 한 번 이상 발생합니다.
그리고 캔버스의 경우 이 프로세스(비트맵 채우기)가 비동기식이 아니기 때문에 이러한 일이 발생할 수 있습니다. 그리고 30밀리초 안에 비트맵을 10번 채울 수 있으며, 한 번만 표시되고 9번은 작업이 유휴 상태였습니다.
따라서 Canvas 주제에서 이미 논의한 것처럼 - 멋지네요! , 프로그래머는 BitMap 채우기 시작 시간을 제어해야 합니다.
행동 모델은 다음과 같을 수 있습니다.
캔버스 속도가 느려진 이유가 거의 확실합니다.
여러 프레임을 하나의 30밀리초 프레임에 넣으려고 했기 때문입니다.
사실 프레임은 초당 약 30프레임보다 더 자주 다시 그려지지 않습니다(ChartRedraw).
여기에서 말했듯이 텍스트 캔버스와 레이블의 차이점은 레이블의 경우 픽셀 배열 채우기가 비동기적으로 발생하고 사용자가 제어하지 않기 때문에 레이블의 경우 픽셀 배열 채우기가 수행되지 않는다는 것입니다. 약 30밀리초마다 한 번 이상 발생합니다.
그리고 캔버스의 경우 이 프로세스(비트맵 채우기)가 비동기식이 아니기 때문에 이러한 일이 발생할 수 있습니다. 그리고 30밀리초 안에 비트맵을 10번 채울 수 있으며, 한 번만 표시되고 9번은 작업이 유휴 상태였습니다.
따라서 Canvas 주제에서 이미 논의한 것처럼 - 멋지네요! , 프로그래머는 BitMap의 채우기 시간을 제어해야 합니다.
행동 모델은 다음과 같을 수 있습니다.
이것에 대해 더 읽을 수 있는 곳이 있습니까? 나는 모든 것을 이해하지만 여전히 주제가 매우 흥미 롭습니다! 이제 비트맵 업데이트를 제어하는 변형을 만들고 테스트해야 합니다. 비트맵이 레이블보다 빠르면 놀랄 것입니다.
여기 내가 말하는 내용을 보여주는 예가 있습니다. 여기 문서에서 스크립트의 기초를 가져왔습니다.
여기서, 처음에는 100번 출력하도록 random array를 구성하고, 각각 100줄씩, 100 Label을 구성한다.
먼저 Label이 있는 100개의 프레임이 표시됩니다.
그런 다음 캔버스 라인이 있는 100개의 프레임.
캔버스 하나.
슬립 루프가 문서화되어 있습니다. 루프에 Sleep(0)이 있으면 완전히 다른 그림이 됩니다. 실험할 수 있습니다.
모든 프레임과 라인은 제어를 위해 번호가 매겨집니다.
동영상을 녹화하고 속도를 30번 늦췄습니다. 이를 통해 100개 중 2개의 프레임만 레이블에 대해 실제로 표시되었음을 알 수 있으며 두 번째 프레임에서는 다른 프레임의 레이블 즉, 비동기 작업이 보입니다.
따라서 Label에 대한 이러한 값은 가짜입니다.
캔버스는 100개 중 60-70개 정도의 프레임에 표시됩니다. 이는 프레임이 30밀리초보다 약간 빠르게 형성되므로 모든 프레임이 형성되지만 모든 프레임이 표시될 시간이 없기 때문에 발생합니다.
상위 2개 옵션으로 실험
주기가 지연됩니다.
출력 행의 수를 늘리면 오류 4001을 잡을 수 있습니다. 이것은 개체가 너무 많을 때 MQ 결함입니다.