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

 
Andrey Khatimlianskii :

렌더러에서 캔버스의 새로 고침 빈도를 인간적으로 제한하는 방법은 무엇입니까?

그래서 느린 속도로 사진이 실시간으로 업데이트되지만 빠른 속도로 테스트가 느려지지 않습니까?

이제 캔버스( 매 틱마다 업데이트되는 경우)는 전체 렌더링 속도를 실제로 저하시킵니다(프로파일링은 렌더링 시간의 80-90%를 보여줍니다). 몇 초 만에 사용자 지정 일시 중지를 피했지만 이것은 기능을 제한하는 목발입니다(저속에서도 사진이 거의 업데이트되지 않음).

너무 자주 업데이트하지 않도록 무엇을 첨부해야합니까? GetMicroseconds?

건너뛸 기능은 무엇입니까?

Andrey, 나는 이미 1년 이상 전에 여기 에 대해 썼습니다.

꽤 잘 나옵니다.
다음은 라이브 비디오입니다(두 개의 캔버스만).

CHARTEVENT_CHART_CHANGE 이벤트가 테스터에서 작동하지 않는다는 것을 추가하기만 하면 됩니다.

그래서 나는 캔버스 형성 블록에 다음을 포함합니다(iCanvas를 사용할 때):

 void BildParabolas() {
   if (Canvas.tester) ChartChanged();
   static uint lastCalc= 0 ;
   uint cur= GetTickCount ();
   if (cur-lastCalc< 17 ) return ;
...

다음은 GIF에 있는 표시기의 OnCalculate 코드 일부입니다.

 static uint lastCalc= 0 ; 
if (Canvas.tester) {
       uint cur= GetTickCount ();
       if (cur-lastCalc> 17 ) {
         lastCalc=cur;
         BildParabolas();
         menu.Draw();
      }
   }

 
Dmitry Fedoseev :
육안으로 캔버스가 훨씬 느린 것을 볼 수 있습니다


 
Taras Slobodyanik :

MT5 테스터에서는 타이머가 작동하며 60초로 설정할 수 있으며 테스트 시간에 따라 1분에 한 번 업데이트됩니다)

나는 일시 중지와 함께 목발에 대해 썼습니다. 맞지 않습니다.

 
Nikolai Semko :

Andrey, 나는 이미 1년 이상 전에 여기 에 대해 썼습니다.

꽤 잘 나옵니다.
다음은 라이브 비디오입니다(2개의 캔버스만).

최대 속도에 관해서는 느린 것처럼 보입니다.

감사합니다. GetTickCount를 사용해 보겠습니다!

 
Andrey Khatimlianskii :

최대 속도에 관해서는 느린 것처럼 보입니다.

감사합니다. GetTickCount를 사용해 보겠습니다!

아니요, 이것은 최대값이 아닙니다. 최대치 이전에 매우 민감합니다.
최대값은 다음과 같습니다.

 
Andrey Khatimlianskii :

최대 속도에 관해서는 느린 것처럼 보입니다.

감사합니다. GetTickCount를 사용해 보겠습니다!

또한 차트 자체와 관련하여 오프셋이 없도록 OBJ_BITMAP_LABEL이 아닌 OBJ_BITMAP 으로 실험을 시도해야 합니다. 바인딩이 XY 좌표가 아닌 시간과 가격에 적용되도록 합니다.
다 해보고 싶은데 손이 안되네요. 이 경우 캔버스를 창 크기보다 크게 만들고 제어 로직을 많이 변경해야 합니다. 전체 캔버스를 다시 그릴 필요가 없고 수직 스케일이 변경되지 않으면 더 작은 부분만 다시 그릴 필요가 있기 때문에 속도가 크게 향상될 것입니다. 어쨌든 캔버스와 메인 그래프의 불균형은 빠른 움직임으로 눈을 아프게하지 않습니다.

 
Nikolai Semko :

아니요, 이것은 최대값이 아닙니다. 최대치 이전에 매우 민감합니다.
최대값은 다음과 같습니다.

"모든 틱"인가요?! 그렇다면 시원합니다. 내가 확인 할게요.


니콜라이 셈코 :

또한 차트 자체와 관련하여 오프셋이 없도록 OBJ_BITMAP_LABEL이 아닌 OBJ_BITMAP 으로 실험을 시도해야 합니다. 바인딩이 XY 좌표가 아닌 시간과 가격에 적용되도록 합니다.
다 해보고 싶은데 손이 안되네요. 이 경우 캔버스를 창 크기보다 크게 만들고 제어 로직을 많이 변경해야 합니다. 아마도 속도 향상이 있을 것입니다. 어쨌든 캔버스와 메인 그래프의 불균형은 빠른 움직임으로 눈을 아프게하지 않습니다.

나는 일반 보드가 있습니다. 차트 링크가 없습니다.

 
Andrey Khatimlianskii :

나는 일반 보드가 있습니다. 차트 링크가 없습니다.

음, 그럼 완전히 정상입니다.
내 gif에서도 하나의 캔버스는 패널이며, 자주 다시 그릴 필요가 없고 새 막대가 도착하는 순간을 포착할 필요가 없기 때문에 최소한의 리소스를 소모합니다.

 
Andrey Khatimlianskii :

"모든 틱"인가요?! 그렇다면 시원합니다. 내가 확인 할게요.

아니요, 3분에 1분 OHLC였습니다. 그러나 나는 모든 진드기를 확인했습니다. 그림은 거의 동일합니다. 결국 이 경우 캔버스를 다시 그리는 것은 틱에 묶이지 않고 실제 시간에만 연결됩니다(테스트 시간이 아님). 저것들. 속도가 높을수록 프레임 밀도가 낮아집니다. 그러나 눈에는 그 차이가 보이지 않습니다.

 
예 ... 애니메이션 GIF, 이것은 확실히 강력한 주장입니다.