Windows 이벤트 모델 의 경우 - 마우스를 빠르게 움직여도 프로세서에 가해지는 부하가 증가하기 시작합니다.
추신: Win10 작업 관리자에서 확인했습니다... 어떤 이유로 프로세서의 부하 증가가 표시되지 않습니다. Win7에서는 정확히 동일한 P에서 마우스를 빠르게 움직이면 부하가 증가합니다. - Win10이 이벤트 모델을 크게 변경했으며 작업 관리자가 다르게 작동할 가능성이 큽니다.
윈10. 다음은 LMB로 텍스트를 누른 상태에서 이 메시지의 입력 창에서 마우스를 움직일 때의 섹션입니다.
그러나 이것은 95-99%를 로드할 때를 제외하고는 OnTimer의 속도를 2배까지 떨어뜨립니다.
타이머도 WinAPI 이벤트이지만 모든 MQL 프로그램이 시스템 타이머를 구독하는지 의심스럽습니다. 이것은 MQL 환경( 가상 머신 )을 에뮬레이트합니다.
알렉세이 마브린 :
메시지 핸들러는 프로세서의 몫을 차지하므로 큐가 없을 때는 단순히 사용하지 않습니다. MT 프로세스의 경우 이러한 부하로 인해 프로세서 시간이 줄어들지 않아야 합니다.
활성 창에는 항상 대기열이 있습니다. 여기에서는 일반적으로 터미널이 차트와 MQL 프로그램 간에 이 대기열을 분산시키는 방법을 커피 찌꺼기에 추측합니다.
글쎄, 결국 - 독점 모드를 얻고 메시지를 처리하지 않으려면 - 많은 옵션이 없습니다. 가장 먼저 오는 것은 응용 프로그램의 독점 전체 화면 모드이지만 그것은 또 다른 이야기이며 " PC 리소스를 위한 전투"가 표시되면 교환에 액세스하고 애플리케이션을 작성한 다음 창을 등록하거나 등록하지 않는 API만 있으면 됩니다.
좋아, 최고 CPU 로드 값을 찾는 것은 흥미롭지 않습니다. - 우리가 Vin에 있는 동안 모든 것이 일반적으로 모든 것이 나에게 적합할 수 있습니다.
네, 내부 차트인줄은 몰랐네요.
음, 프로파일링으로 판단하면 차트가 스크롤될 때 브레이크의 소스는 다음 라인에 있습니다.
활성 스크롤을 사용한 프로파일링:
스크롤 없이 활성 마우스 움직임으로 프로파일링(LMB를 누르지 않음):
추신: 그러므로 브레이크의 근원은 여전히 캔버스가 아니라 오브제입니다.
불행히도 이 코드를 프로파일링하면 공백이 생깁니다. b2828.
불행히도 이 코드를 프로파일링하면 공백이 생깁니다. b2828.
프로파일러 가 아직 완료되지 않은 것을 볼 수 있습니다. 내 것도 때때로 비어있었습니다. 하지만 이제 작동합니다.
이것도 함께 작동
이것은 잘못된 접근 방식입니다. 또한 시각적 테스터는 테스트 프로세스를 완전히 늦추지 않도록 다른 지연된 렌더링 모델을 사용합니다.
알았습니다. 따라서 테스터의 측정 외에도 차트에서 측정을 수행해야 합니다.
나는 그런 말을하지 않았다.
명백한 오류를 지적하고 렌더링 시스템이 어떻게 작동하는지 설명했습니다.
글쎄, 나는 그것을 모두 섞었다. 죄송합니다.
프로파일러 가 아직 완료되지 않은 것을 볼 수 있습니다. 내 것도 때때로 비어있었습니다. 하지만 이제 작동합니다.
이것도 함께 작동
내 b2830도 비어 있습니다.
Windows 이벤트 모델 의 경우 - 마우스를 빠르게 움직여도 프로세서에 가해지는 부하가 증가하기 시작합니다.
추신: Win10 작업 관리자에서 확인했습니다... 어떤 이유로 프로세서의 부하 증가가 표시되지 않습니다. Win7에서는 정확히 동일한 P에서 마우스를 빠르게 움직이면 부하가 증가합니다. - Win10이 이벤트 모델을 크게 변경했으며 작업 관리자가 다르게 작동할 가능성이 큽니다.
윈10. 다음은 LMB로 텍스트를 누른 상태에서 이 메시지의 입력 창에서 마우스를 움직일 때의 섹션입니다.
LMB 없이 여기
윈10. 다음은 LMB로 텍스트를 누른 상태에서 이 메시지의 입력 창에서 마우스를 움직일 때의 섹션입니다.
LMB 없이 여기
시각적으로 아닌
여기 Win7의 가상 머신에서 - 마우스가 움직이지 않으면 3-4% CPU 로드
마우스를 빠르게 움직이면 11-14% 로드
일반적으로 Win의 메시지 큐는 항상 처리되어야 하고 이는 추가 프로세서 주기라는 사실에 대해 이야기하고 있습니다. WinAPI를 사용하여 거기에 있는 메시지 처리기에 대해 읽으십시오.
시각적으로 아닌
여기 Win7의 가상 머신에서 - 마우스가 움직이지 않으면 3-4% CPU 로드
마우스를 빠르게 움직이면 11-14% 로드
일반적으로 Win의 메시지 대기열은 항상 처리되어야 하며 이는 추가 프로세서 주기라는 사실에 대해 이야기하고 있습니다. Google "C ++ Windows 창"
숫자가 더 명확하면 10-15는 변동하고 17-30은 이동하지 않습니다.
그러나 이것은 95-99%를 로드할 때를 제외하고는 2배만큼 OnTimer의 속도를 늦추어야 합니다.
WinAPI를 사용하여 C++로 Windows 창 응용 프로그램을 작성하는 방법에 대한 모든 설명서는 거기에 있는 메시지 처리기에 대해 읽어보십시오.
그러나 이것은 95-99%를 로드할 때를 제외하고는 OnTimer의 속도를 2배까지 떨어뜨립니다.
타이머도 WinAPI 이벤트이지만 모든 MQL 프로그램이 시스템 타이머를 구독하는지 의심스럽습니다. 이것은 MQL 환경( 가상 머신 )을 에뮬레이트합니다.
메시지 핸들러는 프로세서의 몫을 차지하므로 큐가 없을 때는 단순히 사용하지 않습니다. MT 프로세스의 경우 이러한 부하로 인해 프로세서 시간이 줄어들지 않아야 합니다.
활성 창에는 항상 대기열이 있습니다. 여기에서는 일반적으로 터미널이 차트와 MQL 프로그램 간에 이 대기열을 분산시키는 방법을 커피 찌꺼기에 추측합니다.
글쎄, 결국 - 독점 모드를 얻고 메시지를 처리하지 않으려면 - 많은 옵션이 없습니다. 가장 먼저 오는 것은 응용 프로그램의 독점 전체 화면 모드이지만 그것은 또 다른 이야기이며 " PC 리소스를 위한 전투"가 표시되면 교환에 액세스하고 애플리케이션을 작성한 다음 창을 등록하거나 등록하지 않는 API만 있으면 됩니다.
좋아, 최고 CPU 로드 값을 찾는 것은 흥미롭지 않습니다. - 우리가 Vin에 있는 동안 모든 것이 일반적으로 모든 것이 나에게 적합할 수 있습니다.
타이머도 WinAPI 이벤트이지만 모든 MQL 프로그램이 시스템 타이머를 구독하는지 의심스럽습니다. 이것은 MQL 환경( 가상 머신 )을 에뮬레이트합니다.
사실이 아닙니다. 터미널의 타이머와 핸들 수에 버그가 있었다는 것을 기억한다면 이것은 MT의 각 타이머가 시스템 Windows의 타이머일 수 있음을 간접적으로 암시합니다.