캔버스 대 레이블 - 페이지 7

새 코멘트
 
Mihail Matkovskij :

이것에 대해 더 읽을 수 있는 곳이 있습니까? 나는 모든 것을 이해하지만 여전히 주제가 매우 흥미 롭습니다! 이제 비트맵 업데이트를 제어하는 변형을 만들고 테스트해야 합니다. 비트맵이 레이블보다 빠르면 놀랄 것입니다.

BitMap이 MQL5가 아닌 C ++로 채워져 있기 때문에 적은 수의 레이블을 사용하면 캔버스보다 속도 이점이 있음을 완전히 인정합니다. 아니오, 다소 가능성은 없지만 텍스트의 형성은 캔버스에서 동일한 방식으로 발생해야 합니다. 왜냐하면 텍스트 BitMap의 형성은 두 경우 모두 win 함수에 의해 수행되기 때문입니다. Label의 경우 이러한 개체는 여전히 이벤트 속성으로 덮여 있으며(마우스로 끌 수 있음) 궁극적으로 디자인이 더 무거워집니다.

 

Canvas의 속도는 문제입니다.


CPU에 내장된 비디오 카드.


이 코드를 실행 중입니다.

 #include <fxsaber\Usage\Usage.mqh> // https://www.mql5.com/ru/code/33875

void OnInit ()
{  
  USAGE::MinInterval = 100 * 1000 ; // 100 ms.
  
   EventSetMillisecondTimer (( int )USAGE::MinInterval / 1000 );  
}

void OnTimer ()
{
  _USAGE // Расчет нагрузки.

  USAGE::GraphCreate( 1200 , 900 , 200 ); // Вывели график нагрузки.
}

void OnDeinit ( const int )
{
  USAGE::GraphDelete(); // Удалили график нагрузки.
}

간단히 말해서 OnTimer가 100ms마다 실행되는 시간을 측정합니다. 동시에 OnTimer 내부에 측정 일정을 구축합니다. 그런 결과가 나옵니다.

15~20% 먹습니다. 분명히, 브레이크 비디오 카드. 그러나 질문은 다릅니다. 가격 차트를 마우스로 끌기 시작하면(LMB를 누른 상태에서 왼쪽에서 오른쪽으로 이동) 로드가 두 배가 됩니다. 위의 애니메이션을 보면 확실히 알 수 있습니다. 이 기능의 이유는 무엇입니까?


다시 한 번 반복합니다. OnTimer는 마우스로 가격 차트를 움직이면 두 배 더 오래 실행됩니다.

 
fxsaber :

Canvas의 속도는 문제입니다.


CPU에 내장된 비디오 카드.


이 코드를 실행 중입니다.

간단히 말해서 OnTimer가 100ms마다 실행되는 시간을 측정합니다. 동시에 OnTimer 내부에 측정 일정을 구축합니다. 그런 결과가 나옵니다.

15~20% 먹습니다. 분명히, 브레이크 비디오 카드. 그러나 질문은 다릅니다. 가격 차트를 마우스로 끌기 시작하면(LMB를 누른 상태에서 왼쪽에서 오른쪽으로 이동) 로드가 두 배가 됩니다. 위의 애니메이션을 보면 확실히 알 수 있습니다. 이 기능의 이유는 무엇입니까?


다시 한 번 반복합니다. OnTimer는 마우스로 가격 차트를 움직이면 두 배 더 오래 실행됩니다.

필요한 경우(차트 크기가 변경된 경우) 캔버스 크기를 변경하기 위해 라이브러리에 CHARTEVENT_CHART_CHANGE 컨트롤이 있을 가능성이 가장 높지만 알아내려면 엄청나게 느린(여전히) 비동기 ChartGet 함수를 실행해야 합니다.
이것은 브레이크로 이어집니다.
MQ가 CHARTEVENT_CHART_CHANGE 이벤트를 분리하고 개별적으로 수행하는 것이 더 논리적입니다(예: CHARTEVENT_CHART_SIZE_CHANGE). 너무 많은 것이 CHARTEVENT_CHART_CHANGE 이벤트에 채워져 있습니다. 새 막대의 도착, 막대 스크롤, 수직으로 가격 눈금 변경, 창 크기 변경.

 
Nikolai Semko :
BitMap이 MQL5가 아닌 C ++로 채워지기 때문에 적은 수의 레이블을 사용하면 캔버스보다 속도 이점이 있음을 완전히 인정합니다. 아니오, 다소 가능성은 없지만 텍스트의 형성은 캔버스에서 동일한 방식으로 발생해야 합니다. 왜냐하면 텍스트 BitMap의 형성은 두 경우 모두 win 함수에 의해 수행되기 때문입니다. Label의 경우 이러한 개체는 여전히 이벤트 속성으로 덮여 있으며(마우스로 끌 수 있음) 궁극적으로 디자인이 더 무거워집니다.

실제로 레이블이 더 빠를 수 있습니다. 차트에 몇 개나 있느냐에 따라... 업데이트 관리를 제가 했고, 사실 결과에 놀랐습니다. 내가 착각하지 않는 한 눈을 즐겁게 하는 최소 프레임 속도, 24fps에서 제한을 가져왔습니다. 약 41밀리초로 밝혀졌습니다. 나는 Canvas에 한도를 설정했고, 보라, 나는 놀랐다. 가차없는 라벨 리뉴얼에 비하면 그냥 날아간다! 그러나 Label 디스플레이에 대해 동일한 제한을 설정했을 때 Canvas 기반 디스플레이보다 훨씬 빨랐습니다. 그러나 나는 나 자신보다 앞서지 않을 것이며 모든 테스트 결과를 나중에 발표할 것입니다.

 
fxsaber :

가격 차트를 마우스로 끌기 시작하면(LMB를 누른 상태에서 왼쪽에서 오른쪽으로 이동) 로드가 두 배가 됩니다. 위의 애니메이션을 보면 확실히 알 수 있습니다. 이 기능의 이유는 무엇입니까?

Windows 이벤트 모델 사용 - 마우스를 빠르게 움직여도 초점을 맞춘 응용 프로그램에 관계없이 프로세서의 부하가 증가하기 시작합니다.

추신: Win10 작업 관리자에서 확인했습니다... 어떤 이유로 프로세서의 부하 증가가 표시되지 않습니다. Win7에서는 정확히 동일한 P에서 마우스를 빠르게 움직이면 부하가 증가합니다. - Win10이 이벤트 모델을 크게 변경했으며 작업 관리자가 다르게 작동할 가능성이 큽니다.

 
Nikolai Semko :

필요한 경우(차트 크기가 변경된 경우) 캔버스 크기를 변경하기 위해 라이브러리에 CHARTEVENT_CHART_CHANGE 컨트롤이 있을 가능성이 가장 높지만 알아내려면 엄청나게 느린(여전히) 비동기 ChartGet 함수를 실행해야 합니다.
이는 브레이크로 이어집니다.
MQ가 CHARTEVENT_CHART_CHANGE 이벤트를 분리하고 개별적으로 수행하는 것이 더 논리적입니다(예: CHARTEVENT_CHART_SIZE_CHANGE). 너무 많은 것이 CHARTEVENT_CHART_CHANGE 이벤트에 채워져 있습니다. 새 막대의 도착, 막대 스크롤, 수직으로 가격 눈금 변경, 창 크기 변경.

이 중 어느 것도 위의 코드에 없습니다.

 
Igor Makanu :

Windows 이벤트 모델 사용 - 마우스를 빠르게 움직여도 초점을 맞춘 응용 프로그램에 관계없이 프로세서의 부하가 증가하기 시작합니다.

추신: Win10 작업 관리자에서 확인했습니다... 어떤 이유로 프로세서의 부하 증가가 표시되지 않습니다. Win7에서는 정확히 동일한 P에서 마우스를 빠르게 움직이면 부하가 증가합니다. - Win10이 이벤트 모델을 크게 변경했으며 작업 관리자가 다르게 작동할 가능성이 큽니다.

고마워, 몰랐어. 마우스가 MQL 프로그램 속도를 두 번 늦출 수 있다는 사실에 놀랐습니다.

ZY 나에게만 그런 결과가?
fxsaber :

15~20% 먹는다. 분명히, 브레이크 비디오 카드.

 
fxsaber :

고마워, 몰랐어. 마우스가 MQL 프로그램 속도를 두 번 늦출 수 있다는 사실에 놀랐습니다.

그런 다음 진드기 및 기타 것들과 함께 지연이 발생하는 것은 당연합니다. 지뢰밭과 같은 이벤트 모델이 있는 HFT.

 
fxsaber :

이 중 어느 것도 위의 코드에 없습니다.

네, 내부 차트인줄은 몰랐네요.
음, 프로파일링으로 판단하면 차트가 스크롤될 때 브레이크의 소스는 다음 라인에 있습니다.

활성 스크롤을 사용한 프로파일링:

스크롤 없이 활성 마우스 움직임으로 프로파일링(LMB를 누르지 않음):

추신: 그러므로 브레이크의 근원은 여전히 캔버스가 아니라 오브제입니다.

 
Mihail Matkovskij :

차트에서도 확인할 수 있습니다. 그러나 테스터에서 이것을 하는 것이 더 쉬울 것이라고 생각했습니다.

이것은 잘못된 접근 방식입니다. 게다가, 비주얼 테스터는 테스팅 프로세스를 완전히 늦추지 않도록 다른 지연된 렌더링 모델을 가지고 있습니다.

당신이 말했듯이 OBJ_BITMAP_LABEL을 렌더링하는 것보다 레이블의 텍스트를 렌더링하는 데 더 많은 시간이 걸립니다.

나는 그런 말을하지 않았다.

명백한 오류를 지적하고 렌더링 시스템이 어떻게 작동하는지 설명했습니다.

1234567891011121314...18
새 코멘트
사유: