이것은 중간 업데이트입니다. 며칠 후에 다음 버전을 출시할 예정입니다. 프로그램과 컨트롤의 상호작용을 위한 새로운 기능이 추가될 예정입니다.
저는 2470과 새 빌드 두 가지로 작업하고 있습니다. 대부분의 개발은 이전 빌드에서 이루어집니다. 컴파일 속도가 4초 대 26~32초로 더 빠릅니다. 새 빌드는 약간 다르게 작동하며 시각적으로 눈에 띄게 달라집니다. 때로는 더 빠르고 때로는 더 느립니다. 그냥 그렇게 느껴질 수도 있습니다. 차이를 찾기는 어렵지만 제게는 차이가있는 것 같습니다. 이전 빌드의 인터페이스가 날아갑니다. 새 빌드에서는. 거의 날아갑니다. 익숙하기 때문일 수도 있습니다.
그러나 뉘앙스가 있습니다. 예를 들어 차트 높이와 너비의 잘못된 값이 반환 될 때 차트 전환에 문제가 있습니다. 이로 인해 작업 표시 줄이 점프합니다. 이 문제를 우회 할 수 있었지만 작업 표시 줄은 차트 크기 조정의 다른 이벤트에 반응하지 않습니다. 결국 그대로 두기로 결정했습니다. 작업 표시 줄은 차트 전환시 점프하지만 (잘못된 값을 반환하는 문제가있는 한) 다른 이벤트에는 정상적으로 적응합니다.
하지만 그게 다가 아닙니다. 차트 크기 조정 이벤트가 즉시 발생하지 않고 0.5초의 일시 정지가 있는 것으로 나타났습니다. 이 지연은 작업 표시 줄을 다시 그리는 시간에 겹쳐져 적절한 지연이 발생합니다. 여기서 나는 무력합니다.
물론 그래픽을 상당히 가속화했지만 코드에 최적화되지 않은 다른 솔루션이 여전히 있습니다. 열심히 노력하고 있습니다. 대부분 창 포커스 전환과 다시 그리기 대기열에 관한 것입니다. 일부 불필요한 호출이 발생합니다. 작업 표시줄이 지연됩니다. 전부는 아니지만 수정할 시간이 있는 것은 수정했습니다. 하지만 나머지는 앞으로 며칠 안에 해결해야 할 문제입니다. 그렇지 않으면 개선할 것이 별로 없습니다... 코드를 향기롭게 만들기 위해 빗질하고 향수를 뿌려야 할지도 모르죠)).
일반적으로 최적화되지 않은 나머지 모든 솔루션을 디버그하면... 물론 MQL 프로그램에서 사용할 수 있는 속도 내에서 말이죠.
그래픽은 물론 상당히 빨라졌지만 코드에는 여전히 최적화되지 않은 몇 가지 다른 솔루션이 있습니다. 열심히 노력하고 있습니다. 대부분 창 포커스 전환 및 다시 그리기 대기열에 관한 것입니다. 일부 불필요한 호출이 발생합니다. 작업 표시줄이 지연됩니다. 전부는 아니지만 수정할 시간이 있는 것은 수정했습니다. 하지만 나머지는 앞으로 며칠이 걸릴 문제입니다. 그렇지 않으면 개선할 것이 별로 없습니다... 코드를 향기롭게 만들기 위해 빗질하고 향수를 뿌려야 할지도 모르죠)).
일반적으로 최적화되지 않은 나머지 모든 솔루션을 디버그하면... 물론 MQL 프로그램에서 사용할 수 있는 속도 내에서 말이죠.
릴리스를 가져옵니다.
분명히 말씀드리자면 여기서 말하는 것은 속도입니다. 초점 변경 이벤트에서 창 다시 그리기 결함을 수정하면 인터페이스 속도가 MQL 프로그램의 상한선에 도달하게 됩니다. 작업 표시 줄의 지연은 부분적으로 수정할 수 있습니다. 작업 표시 줄의 메커니즘에 동적 창의 원리를 적용하는 좋은 해결책을 생각해 냈습니다. 크기를 조정할 때 프레임에 의해 당겨질 때 속도가 느려지지 않습니다. 더 빠르고 눈에 띄지 않게 조정됩니다. 물론 불필요한 다시 그리기를 취소해야합니다. 이것은 필수입니다. 그러나 차트 이벤트 자체가 지연되어 프로그램에 발생하면 작업 표시 줄 반응의 가시적 인 지연이 불가피하지만 아무 관련이 없습니다.
저는 지연을 확인하고 렌더링 브레이크를 찾는 데 많은 시간을 보냈습니다. 칸버스 레이아웃을 담당하는 블록은 ResourceCreate() 함수에서 리소스를 생성하는 배열을 초기화하기 전에 창 세부 정보에서 루프의 경계를 정의하는 방식으로 구축되었습니다. 이 작업은 들어오는 이벤트를 확인하도록 구성된 조건 필터의 도움으로 수행됩니다. 블록을 호출하는 각 이벤트에는 그리기 경계가 지정됩니다. 예를 들어, 커서 가리키기에 대한 요소의 반응 이벤트에서는 특정 요소의 세부 정보에만 루프 경계가 있는 필터가 활성화됩니다. 블록은 촬영한 이미지에서 해당 세부 사항만 선택합니다. 그리고 세부 사항을 순환하는 동안 나머지 이미지 중에서 해당 부분만 선택적으로 그립니다. 정확한 요소의 정확한 디테일을 초기화하고 그릴 위치를 정확하게 찾습니다. 동시에 나머지 이미지 공간을 올바르게 우회합니다.
하지만 가속은 그뿐만이 아닙니다. 블록은 캔버스의 색상이 필요한 값과 일치하는 경우 캔버스의 점을 초기화하지 않습니다. 또한 배열을 '실행'하는 것이 아니라 거리를 '점프'하며 이동합니다. 이렇게 하면 수십만 번의 반복 주기가 줄어듭니다.
그뿐만이 아닙니다. 이미지 배열은 글로벌(전역 수준에서 선언됨)이기 때문에 항상 마지막 이미지의 변경 사항을 메모리에 저장합니다. 그리고 동일한 캔버스에서 변경 사항이 계속 발생하면 매번 배열을 지우는 대신 저장된 이미지가 사용됩니다. 다음 이벤트에서 리소스 이름이 변경되지 않으면 ResourceReadImage()를 호출할 필요가 없으며 캔버스 배열을 다시 채워서 전송할 필요도 없습니다. 블록은 ResourceReadImage()를 호출하지 않고 나머지 데이터로 계속 작업하고 변경 후 ResourceCreate()로 이미지를 업데이트합니다.
이렇게 하면 ResourceReadImage() 호출 시간을 많이 절약할 수 있습니다. 또한 배열을 지우고 채울 때도 마찬가지입니다. 전역 메모리를 잘 활용하고 있지 않나요?
창을 다시 그릴 때는 블록이 전혀 호출되지 않습니다. 창 컴포넌트가 지워지고 생성되며 이전에 저장된 리소스가 첨부됩니다. 렌더링이 없습니다.
이 모든 것에도 불구하고 여전히 지연이 있으며 피할 수 없습니다. 무슨 일이 일어나고 있는지 설명하겠습니다.
창을 처음 열 때, 탭을 처음 열 때, 트리 목록을 만들 때, 큰 공간을 최소화하거나 모델링 해제할 때 캔버스를 완전히 다시 그려야 합니다. 나중에 여러 번 효율적으로 연결/변경할 수 있는 이미지 리소스를 만드는 순간까지, 항상 한 번은 처음부터 완전한 이미지를 그려야 합니다. 첫 번째 그림은 항상 가장 긴 그림입니다. 저장할 것도 없고, 저장된 이미지도 없습니다. 처음 열었을 때 항상 지연을 볼 수 있습니다. 피할 수 없습니다.
그러나 여기에도 좋은 해결책이 있습니다. 창 열기 지연을 로딩 이벤트로 이동하는 것입니다. 내 말은 : 백그라운드에서 생성자를로드하는 단계에서 모든 이미지를 그려서 미리 리소스에 저장하여 열 때 모든 것이 준비되도록합니다. 그러면 사용자가 처음으로 창을 열 때 지연이 발생하지 않습니다. 물론 이것은 훌륭하지만 단점이 있습니다. 첫 번째 열기의 지연이 로딩 지연으로 바뀌고 시간이 늘어납니다. 얼마라고 말하기는 어렵습니다. 평균적으로 1초 이내라고 생각합니다. 특정 인터페이스에 따라 다릅니다.
이 옵션이 더 바람직하다고 생각합니다. 디자이너/사용자 인터페이스가 조금 더 오래 로드되지만 시각적인 시작 지연은 더 이상 없을 것입니다.
이에 대한 여러분의 의견을 듣고 싶습니다.
추가했습니다:
파일을 처음 로드한 후 인터페이스 리소스를 저장하는 아이디어가 있었습니다. 그러면 필요한 리소스가 이미 디자이너/엔진에서 사용할 수 있기 때문에 후속 로드가 훨씬 빨라질 것입니다. 생각해 볼 필요가 있습니다.
대신 향후 릴리스에서 카탈로그를 영어로 변경하는 것을 고려해 주시겠습니까? 카탈로그 이름이 포함된 소스 코드 파일이 텍스트로 대체됩니다.
네, 물론입니다. 이미 생각했습니다. 카탈로그 이름이 영어로 된 특별 릴리스 버전을 만들겠습니다.
여기서는 파일은 확인하지 않고 댓글만 확인합니다. 하지만 그 '지연'은 속도와 관련이 있는 것이 아니라 새 리소스를 완전히 만들기 전에 ChartRedraw를 사용하는 것과 관련이 있는 것 같습니다. 빈 캔버스로 블링크를 한 다음 새 캔버스를 표시하기 때문입니다.
물론이죠. 생각 좀 해봤습니다. 영문 카탈로그 이름이 포함된 특별 릴리스를 만들겠습니다.
영어 카탈로그가 포함 된 특별 릴리스를 만들지 말고 카탈로그 이름을 영어로 변경하고 다음 단계는 파일 이름을 영어로 변경하고 소스 코드는 여전히 러시아어로 작성하는 것이 좋습니다.
저도 동의합니다. 점차적으로 디렉터리 이름을 영문으로 바꾸도록 하겠습니다. 그렇게 하는 것이 더 합리적일 것입니다.
파일은 확인하지 않았고 여기 댓글만 확인했습니다. 하지만 이 '지연'은 속도와 관련이 있는 것이 아니라 새 리소스가 완전히 생성되기 전에 ChartRedraw를 사용하는 것과 관련이 있는 것 같습니다. 빈 캔버스를 깜박인 다음 새 캔버스를 표시하기 때문입니다.
흥미로운 아이디어네요, 테스트해 보겠습니다. 고마워요.
그래서 업데이트...
이것은 중간 업데이트입니다. 며칠 후에 다음 버전을 출시할 예정입니다. 프로그램과 컨트롤의 상호작용을 위한 새로운 기능이 추가될 예정입니다.
저는 2470과 새 빌드 두 가지로 작업하고 있습니다. 대부분의 개발은 이전 빌드에서 이루어집니다. 컴파일 속도가 4초 대 26~32초로 더 빠릅니다. 새 빌드는 약간 다르게 작동하며 시각적으로 눈에 띄게 달라집니다. 때로는 더 빠르고 때로는 더 느립니다. 그냥 그렇게 느껴질 수도 있습니다. 차이를 찾기는 어렵지만 제게는 차이가있는 것 같습니다. 이전 빌드의 인터페이스가 날아갑니다. 새 빌드에서는. 거의 날아갑니다. 익숙하기 때문일 수도 있습니다.
그러나 뉘앙스가 있습니다. 예를 들어 차트 높이와 너비의 잘못된 값이 반환 될 때 차트 전환에 문제가 있습니다. 이로 인해 작업 표시 줄이 점프합니다. 이 문제를 우회 할 수 있었지만 작업 표시 줄은 차트 크기 조정의 다른 이벤트에 반응하지 않습니다. 결국 그대로 두기로 결정했습니다. 작업 표시 줄은 차트 전환시 점프하지만 (잘못된 값을 반환하는 문제가있는 한) 다른 이벤트에는 정상적으로 적응합니다.
하지만 그게 다가 아닙니다. 차트 크기 조정 이벤트가 즉시 발생하지 않고 0.5초의 일시 정지가 있는 것으로 나타났습니다. 이 지연은 작업 표시 줄을 다시 그리는 시간에 겹쳐져 적절한 지연이 발생합니다. 여기서 나는 무력합니다.
물론 그래픽을 상당히 가속화했지만 코드에 최적화되지 않은 다른 솔루션이 여전히 있습니다. 열심히 노력하고 있습니다. 대부분 창 포커스 전환과 다시 그리기 대기열에 관한 것입니다. 일부 불필요한 호출이 발생합니다. 작업 표시줄이 지연됩니다. 전부는 아니지만 수정할 시간이 있는 것은 수정했습니다. 하지만 나머지는 앞으로 며칠 안에 해결해야 할 문제입니다. 그렇지 않으면 개선할 것이 별로 없습니다... 코드를 향기롭게 만들기 위해 빗질하고 향수를 뿌려야 할지도 모르죠)).
일반적으로 최적화되지 않은 나머지 모든 솔루션을 디버그하면... 물론 MQL 프로그램에서 사용할 수 있는 속도 내에서 말이죠.
릴리스를 가져옵니다.
그래서 업데이트...
...
그래픽은 물론 상당히 빨라졌지만 코드에는 여전히 최적화되지 않은 몇 가지 다른 솔루션이 있습니다. 열심히 노력하고 있습니다. 대부분 창 포커스 전환 및 다시 그리기 대기열에 관한 것입니다. 일부 불필요한 호출이 발생합니다. 작업 표시줄이 지연됩니다. 전부는 아니지만 수정할 시간이 있는 것은 수정했습니다. 하지만 나머지는 앞으로 며칠이 걸릴 문제입니다. 그렇지 않으면 개선할 것이 별로 없습니다... 코드를 향기롭게 만들기 위해 빗질하고 향수를 뿌려야 할지도 모르죠)).
일반적으로 최적화되지 않은 나머지 모든 솔루션을 디버그하면... 물론 MQL 프로그램에서 사용할 수 있는 속도 내에서 말이죠.
릴리스를 가져옵니다.
분명히 말씀드리자면 여기서 말하는 것은 속도입니다. 초점 변경 이벤트에서 창 다시 그리기 결함을 수정하면 인터페이스 속도가 MQL 프로그램의 상한선에 도달하게 됩니다. 작업 표시 줄의 지연은 부분적으로 수정할 수 있습니다. 작업 표시 줄의 메커니즘에 동적 창의 원리를 적용하는 좋은 해결책을 생각해 냈습니다. 크기를 조정할 때 프레임에 의해 당겨질 때 속도가 느려지지 않습니다. 더 빠르고 눈에 띄지 않게 조정됩니다. 물론 불필요한 다시 그리기를 취소해야합니다. 이것은 필수입니다. 그러나 차트 이벤트 자체가 지연되어 프로그램에 발생하면 작업 표시 줄 반응의 가시적 인 지연이 불가피하지만 아무 관련이 없습니다.
그렇지 않으면 인터페이스 개발 및 개선 방향이 많이 있습니다.
인터페이스 속도에 대해 몇 마디 더 말씀드리겠습니다.
저는 지연을 확인하고 렌더링 브레이크를 찾는 데 많은 시간을 보냈습니다. 칸버스 레이아웃을 담당하는 블록은 ResourceCreate() 함수에서 리소스를 생성하는 배열을 초기화하기 전에 창 세부 정보에서 루프의 경계를 정의하는 방식으로 구축되었습니다. 이 작업은 들어오는 이벤트를 확인하도록 구성된 조건 필터의 도움으로 수행됩니다. 블록을 호출하는 각 이벤트에는 그리기 경계가 지정됩니다. 예를 들어, 커서 가리키기에 대한 요소의 반응 이벤트에서는 특정 요소의 세부 정보에만 루프 경계가 있는 필터가 활성화됩니다. 블록은 촬영한 이미지에서 해당 세부 사항만 선택합니다. 그리고 세부 사항을 순환하는 동안 나머지 이미지 중에서 해당 부분만 선택적으로 그립니다. 정확한 요소의 정확한 디테일을 초기화하고 그릴 위치를 정확하게 찾습니다. 동시에 나머지 이미지 공간을 올바르게 우회합니다.
하지만 가속은 그뿐만이 아닙니다. 블록은 캔버스의 색상이 필요한 값과 일치하는 경우 캔버스의 점을 초기화하지 않습니다. 또한 배열을 '실행'하는 것이 아니라 거리를 '점프'하며 이동합니다. 이렇게 하면 수십만 번의 반복 주기가 줄어듭니다.
그뿐만이 아닙니다. 이미지 배열은 글로벌(전역 수준에서 선언됨)이기 때문에 항상 마지막 이미지의 변경 사항을 메모리에 저장합니다. 그리고 동일한 캔버스에서 변경 사항이 계속 발생하면 매번 배열을 지우는 대신 저장된 이미지가 사용됩니다. 다음 이벤트에서 리소스 이름이 변경되지 않으면 ResourceReadImage()를 호출할 필요가 없으며 캔버스 배열을 다시 채워서 전송할 필요도 없습니다. 블록은 ResourceReadImage()를 호출하지 않고 나머지 데이터로 계속 작업하고 변경 후 ResourceCreate()로 이미지를 업데이트합니다.
이렇게 하면 ResourceReadImage() 호출 시간을 많이 절약할 수 있습니다. 또한 배열을 지우고 채울 때도 마찬가지입니다. 전역 메모리를 잘 활용하고 있지 않나요?
창을 다시 그릴 때는 블록이 전혀 호출되지 않습니다. 창 컴포넌트가 지워지고 생성되며 이전에 저장된 리소스가 첨부됩니다. 렌더링이 없습니다.
이 모든 것에도 불구하고 여전히 지연이 있으며 피할 수 없습니다. 무슨 일이 일어나고 있는지 설명하겠습니다.
창을 처음 열 때, 탭을 처음 열 때, 트리 목록을 만들 때, 큰 공간을 최소화하거나 모델링 해제할 때 캔버스를 완전히 다시 그려야 합니다. 나중에 여러 번 효율적으로 연결/변경할 수 있는 이미지 리소스를 만드는 순간까지, 항상 한 번은 처음부터 완전한 이미지를 그려야 합니다. 첫 번째 그림은 항상 가장 긴 그림입니다. 저장할 것도 없고, 저장된 이미지도 없습니다. 처음 열었을 때 항상 지연을 볼 수 있습니다. 피할 수 없습니다.
그러나 여기에도 좋은 해결책이 있습니다. 창 열기 지연을 로딩 이벤트로 이동하는 것입니다. 내 말은 : 백그라운드에서 생성자를로드하는 단계에서 모든 이미지를 그려서 미리 리소스에 저장하여 열 때 모든 것이 준비되도록합니다. 그러면 사용자가 처음으로 창을 열 때 지연이 발생하지 않습니다. 물론 이것은 훌륭하지만 단점이 있습니다. 첫 번째 열기의 지연이 로딩 지연으로 바뀌고 시간이 늘어납니다. 얼마라고 말하기는 어렵습니다. 평균적으로 1초 이내라고 생각합니다. 특정 인터페이스에 따라 다릅니다.
이 옵션이 더 바람직하다고 생각합니다. 디자이너/사용자 인터페이스가 조금 더 오래 로드되지만 시각적인 시작 지연은 더 이상 없을 것입니다.
이에 대한 여러분의 의견을 듣고 싶습니다.
추가했습니다:
파일을 처음 로드한 후 인터페이스 리소스를 저장하는 아이디어가 있었습니다. 그러면 필요한 리소스가 이미 디자이너/엔진에서 사용할 수 있기 때문에 후속 로드가 훨씬 빨라질 것입니다. 생각해 볼 필요가 있습니다.