오류, 버그, 질문 - 페이지 976 1...969970971972973974975976977978979980981982983...3184 새 코멘트 Renat Fatkhullin 2013.04.27 13:32 #9751 테스트를 해보고 결과를 올리겠습니다. Anatoli Kazharski 2013.04.27 13:37 #9752 voix_kas : ... 이상하게도 반대 그림이 있습니다. 나는이 출력이 있습니다 : 거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼 오류, 버그, 질문 레나트 , 2013.04.27 13:32 테스트를 해보고 결과를 올리겠습니다. 흥미롭네요. Renat Fatkhullin 2013.04.27 13:43 #9753 레이블을 테스트할 때 렌더링이 MQL5 시스템에서 완전히 제거되고 인터페이스 스레드에서 그려지는 것을 완전히 잊었습니다. MQL5에서는 레이블 설명만 수정됩니다. 그러나 비트맵을 그릴 때 거의 모든 작업은 MQL5 내에서 이루어지며 인터페이스 스트림에는 매우 빠른 단일 BitBlt만 남습니다. 즉, 레이블의 표시가 전혀 테스트되지 않았기 때문에 테스트는 완전히 잘못된 것입니다. 차트 새로 고침은 그리기 위해 인터페이스 스레드에만 알림을 보내는 비동기 명령입니다. ChartRedraw 비용이 포함된 스크린샷에서 볼 수 있듯이. [삭제] 2013.04.27 13:46 #9754 Renat : 추가 색상 정규화 오버헤드가 발생하므로 Argb_normalize를 사용하면 안 됩니다. 단순한 것을 순수한 색으로 칠하는 것이 좋습니다. 알파 채널은 미학으로 사람들을 사로잡습니다. 텍스트가 "투명"한 경우 차트/막대 배경에 표시됩니다. 응용 분야의 분할에 대한 명백한 결론은 그 자체를 암시합니다. 메시지/통계만 표시해야 하는 경우 텍스트 레이블이 더 빠릅니다. 컨트롤 (예: 버튼)을 만드는 경우 - 또한 옵션이 없는 비트맵. 그러면 큰 실망 없이 알파 채널/투명도 없이 전체 직사각형 영역을 단색으로 채울 수 있습니다. --- 2013.04.27 13:46 #9755 voix_kas : 루프에서 ChartRedraw() 함수를 제거하는 것은 올바르지 않습니다. 텍스트 레이블 속성을 변경하는 "원자적 작업"이 터미널의 비디오 엔진에서 어떤 식으로든 처리되지 않기 때문입니다. 아하, 어레이 작업이 비디오 엔진에 의해 처리되지 않는 것과 정확히 같습니다. 나는 작업이 더 빨리 작동하는 것을 찾는 것임을 반복합니다. 비트맵 변경 또는 레이블 변경 비트맵 생성 손실 - 이것은 분명합니다. 두 경우 모두 차트를 그리는 것은 논쟁의 여지가 있고 부차적인 문제입니다. 당신은 결과에 대해 스스로 생각합니다. 라벨을 변경하는 1주기당 4초를 볼 수 있나요???? 이것은 넌센스입니다. 레이블 변경 사항은 차트 렌더링 하위 시스템에서 혼합하지 않고 변경 사항에 대해 순수하게 확인해야 합니다. 그렇지 않으면 비트맵과 비교할 수 있는 숫자가 표시됩니다. --- 2013.04.27 13:53 #9756 Renat : 레이블을 테스트할 때 렌더링이 MQL5 시스템에서 완전히 제거되고 인터페이스 스레드에서 그려지는 것을 완전히 잊었습니다. MQL5에서는 레이블 설명만 수정됩니다. 하지만 비트맵을 그릴 때 거의 모든 작업이 MQL5 내부에서 이루어집니다. 그러나 동시에 레이블은 비트맵보다 속도가 더 빠르게 변경됩니다. 느린 GDI 기능으로 인해. 즉, 레이블의 표시가 전혀 테스트되지 않았기 때문에 테스트는 완전히 잘못된 것입니다. 차트 새로 고침은 그리기 위해 인터페이스 스레드에만 알림을 보내는 비동기 명령입니다. ChartRedraw의 비용이 포함된 스크린샷에서 볼 수 있듯이. 그게 다야 몇 가지 특정 어려운 작업의 조건에서 테스트를 수행해야한다고 생각합니다. 누가 벤치마크를 사용하여 그러한 작업을 수행할 것인가? - 많은 레이블(사각형)과 비트맵을 사용하여 그래프(예: 사인파) 그리기. - Excel 테이블(사각형+텍스트 레이블) 및 비트맵 그리기. 음, MT 그래픽을 비트맵으로 대체할 수 있는 기타 옵션이 있습니다. 하나 의 비트맵과 많은 MT 개체를 지원하기 위한 리소스 비용을 확인해야 합니다. + 채워진 영역의 크기에 대한 의존성. Renat Fatkhullin 2013.04.27 13:55 #9757 태그 테스트는 또한 읽지 않고 쓰기 위한 태그로 매우 경제적인 단방향 작업이 있음을 보여줍니다. 이 경우 쓰기당 명령 스트림은 가능한 한 빠르게 파이프됩니다(이 경우 특히 효율적인 시스템을 사용합니다). 그러나 실제 작업에서 자주 발생하는 쓰기와 함께 이러한 개체의 읽기를 사용하면 속도가 급격히 떨어집니다. 업데이트: 태그 테스트 예제에도 치명적인 오류 가 있습니다. 26개가 아닌 하나의 태그만 수정됩니다. 소스를 살펴보세요. [삭제] 2013.04.27 13:55 #9758 Renat : 즉, 레이블의 표시가 전혀 테스트되지 않았기 때문에 테스트는 완전히 잘못된 것입니다. 세르게예프 : 레이블 변경 사항은 차트 렌더링 하위 시스템을 혼합하지 않고 변경 사항만 확인해야 합니다. 물론 동의하지 않습니다. 인수: 사용자가 각 틱 에서 가능한 한 자주 상황(통계)의 변화를 보는 것이 바람직합니다. 따라서 통계를 업데이트한 후에는 = ChartRedraw()로 표시되어야 합니다. 이것은 말하자면 직접적으로 적용되는/실용적인 성능의 측면에서 볼 수 있습니다. 진공 상태의 구형 벤치마크의 경우 이는 선택 사항입니다. Renat Fatkhullin 2013.04.27 13:57 #9759 sergeev : 그러나 동시에 레이블은 비트맵보다 속도가 더 빠르게 변경됩니다. 느린 GDI 기능으로 인해. 아니요, 레이블을 수정할 때 GDI 메서드가 호출되지 않습니다. 마크는 µl5에 전혀 표시되지 않습니다! [삭제] 2013.04.27 13:58 #9760 Renat : 레이블 테스트 예제 에도 치명적인 오류 가 있습니다 . 26개가 아닌 하나의 레이블만 수정됩니다. 소스를 보십시오. 설명이 아닌 표시기의 값을 정확하게 표시하도록 설계된 레이블의 전체(절반)에서 텍스트가 변경됩니다. 스크립트를 실행하면 볼 수 있습니다. 아니면 당신을 이해하지 못했습니다. 구체적으로 어떤 라인을 말씀하시는 건가요? 1...969970971972973974975976977978979980981982983...3184 새 코멘트 트레이딩 기회를 놓치고 있어요: 무료 트레이딩 앱 복사용 8,000 이상의 시그널 금융 시장 개척을 위한 경제 뉴스 등록 로그인 공백없는 라틴 문자 비밀번호가 이 이메일로 전송될 것입니다 오류 발생됨 Google으로 로그인 웹사이트 정책 및 이용약관에 동의합니다. 계정이 없으시면, 가입하십시오 MQL5.com 웹사이트에 로그인을 하기 위해 쿠키를 허용하십시오. 브라우저에서 필요한 설정을 활성화하시지 않으면, 로그인할 수 없습니다. 사용자명/비밀번호를 잊으셨습니까? Google으로 로그인
...
이상하게도 반대 그림이 있습니다.
나는이 출력이 있습니다 :
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
오류, 버그, 질문
레나트 , 2013.04.27 13:32
테스트를 해보고 결과를 올리겠습니다.레이블을 테스트할 때 렌더링이 MQL5 시스템에서 완전히 제거되고 인터페이스 스레드에서 그려지는 것을 완전히 잊었습니다. MQL5에서는 레이블 설명만 수정됩니다.
그러나 비트맵을 그릴 때 거의 모든 작업은 MQL5 내에서 이루어지며 인터페이스 스트림에는 매우 빠른 단일 BitBlt만 남습니다.
즉, 레이블의 표시가 전혀 테스트되지 않았기 때문에 테스트는 완전히 잘못된 것입니다. 차트 새로 고침은 그리기 위해 인터페이스 스레드에만 알림을 보내는 비동기 명령입니다. ChartRedraw 비용이 포함된 스크린샷에서 볼 수 있듯이.
추가 색상 정규화 오버헤드가 발생하므로 Argb_normalize를 사용하면 안 됩니다. 단순한 것을 순수한 색으로 칠하는 것이 좋습니다.
알파 채널은 미학으로 사람들을 사로잡습니다. 텍스트가 "투명"한 경우 차트/막대 배경에 표시됩니다. 응용 분야의 분할에 대한 명백한 결론은 그 자체를 암시합니다.
메시지/통계만 표시해야 하는 경우 텍스트 레이블이 더 빠릅니다. 컨트롤 (예: 버튼)을 만드는 경우 - 또한 옵션이 없는 비트맵. 그러면 큰 실망 없이 알파 채널/투명도 없이 전체 직사각형 영역을 단색으로 채울 수 있습니다.
루프에서 ChartRedraw() 함수를 제거하는 것은 올바르지 않습니다. 텍스트 레이블 속성을 변경하는 "원자적 작업"이 터미널의 비디오 엔진에서 어떤 식으로든 처리되지 않기 때문입니다.
아하, 어레이 작업이 비디오 엔진에 의해 처리되지 않는 것과 정확히 같습니다.
나는 작업이 더 빨리 작동하는 것을 찾는 것임을 반복합니다. 비트맵 변경 또는 레이블 변경
비트맵 생성 손실 - 이것은 분명합니다.
두 경우 모두 차트를 그리는 것은 논쟁의 여지가 있고 부차적인 문제입니다.
당신은 결과에 대해 스스로 생각합니다. 라벨을 변경하는 1주기당 4초를 볼 수 있나요???? 이것은 넌센스입니다.
레이블 변경 사항은 차트 렌더링 하위 시스템에서 혼합하지 않고 변경 사항에 대해 순수하게 확인해야 합니다.
그렇지 않으면 비트맵과 비교할 수 있는 숫자가 표시됩니다.
레이블을 테스트할 때 렌더링이 MQL5 시스템에서 완전히 제거되고 인터페이스 스레드에서 그려지는 것을 완전히 잊었습니다. MQL5에서는 레이블 설명만 수정됩니다.
하지만 비트맵을 그릴 때 거의 모든 작업이 MQL5 내부에서 이루어집니다.
그러나 동시에 레이블은 비트맵보다 속도가 더 빠르게 변경됩니다. 느린 GDI 기능으로 인해.
즉, 레이블의 표시가 전혀 테스트되지 않았기 때문에 테스트는 완전히 잘못된 것입니다. 차트 새로 고침은 그리기 위해 인터페이스 스레드에만 알림을 보내는 비동기 명령입니다. ChartRedraw의 비용이 포함된 스크린샷에서 볼 수 있듯이.
그게 다야
몇 가지 특정 어려운 작업의 조건에서 테스트를 수행해야한다고 생각합니다. 누가 벤치마크를 사용하여 그러한 작업을 수행할 것인가?
- 많은 레이블(사각형)과 비트맵을 사용하여 그래프(예: 사인파) 그리기.
- Excel 테이블(사각형+텍스트 레이블) 및 비트맵 그리기.
음, MT 그래픽을 비트맵으로 대체할 수 있는 기타 옵션이 있습니다.
하나 의 비트맵과 많은 MT 개체를 지원하기 위한 리소스 비용을 확인해야 합니다. + 채워진 영역의 크기에 대한 의존성.
태그 테스트는 또한 읽지 않고 쓰기 위한 태그로 매우 경제적인 단방향 작업이 있음을 보여줍니다. 이 경우 쓰기당 명령 스트림은 가능한 한 빠르게 파이프됩니다(이 경우 특히 효율적인 시스템을 사용합니다).
그러나 실제 작업에서 자주 발생하는 쓰기와 함께 이러한 개체의 읽기를 사용하면 속도가 급격히 떨어집니다.
업데이트: 태그 테스트 예제에도 치명적인 오류 가 있습니다. 26개가 아닌 하나의 태그만 수정됩니다. 소스를 살펴보세요.
즉, 레이블의 표시가 전혀 테스트되지 않았기 때문에 테스트는 완전히 잘못된 것입니다.
레이블 변경 사항은 차트 렌더링 하위 시스템을 혼합하지 않고 변경 사항만 확인해야 합니다.
물론 동의하지 않습니다. 인수: 사용자가 각 틱 에서 가능한 한 자주 상황(통계)의 변화를 보는 것이 바람직합니다. 따라서 통계를 업데이트한 후에는 = ChartRedraw()로 표시되어야 합니다.
이것은 말하자면 직접적으로 적용되는/실용적인 성능의 측면에서 볼 수 있습니다.
진공 상태의 구형 벤치마크의 경우 이는 선택 사항입니다.
그러나 동시에 레이블은 비트맵보다 속도가 더 빠르게 변경됩니다. 느린 GDI 기능으로 인해.
레이블 테스트 예제 에도 치명적인 오류 가 있습니다 . 26개가 아닌 하나의 레이블만 수정됩니다. 소스를 보십시오.
설명이 아닌 표시기의 값을 정확하게 표시하도록 설계된 레이블의 전체(절반)에서 텍스트가 변경됩니다. 스크립트를 실행하면 볼 수 있습니다.
아니면 당신을 이해하지 못했습니다. 구체적으로 어떤 라인을 말씀하시는 건가요?