이제 주요 과제는 사용자가 인터페이스 컨트롤을 프로그래밍 방식으로 제어할 수 있도록 하는 것입니다.
사용자 프로그램과 엔진의 공생 조합에서 그래픽 코어는 양 당사자의 알고리즘에 대해 글로벌 수준에서 볼 수 있기 때문에 기술적으로이 작업은 어렵지 않습니다. 문제는 사용자가 커널로 작업하는 방법을 모른다는 것입니다. 그는 요소 관리의 원리를 모르고 이해하지 못합니다. 따라서 커널에 액세스하고 값을 변경할 수있는 기능인 친숙한 래퍼를 제공해야합니다.
그러나 뉘앙스가 있습니다. 함수 이름이 너무 깁니다. 결국 대화형 요소의 각 기능 래퍼에는 요소와 창의 이름이 포함되어야 합니다. 이는 이름 사이의 방향성을 위해 필요합니다. 그렇지 않으면 사용자가 쉽게 혼동하고 함수 래퍼를 이해하지 못할 것입니다. 또한 이름이 일치 할 수 있으며 이것은 전혀 좋지 않습니다. 따라서 요소의 이름과 창의 이름이라는 두 가지 구성 요소에서 이름을 생성해야합니다. 그러면 혼동은 없지만 래퍼의 이름이 너무 길어집니다. 특히 전달된 매개 변수의 측면에서. 또한 함수에 접두사를 추가하여 인텔리센스를 통해 빠르게 찾을 수 있도록 해야 합니다. 이렇게 하면 팝업 샘플을 효율적으로 필터링할 수 있습니다. 편리합니다. 하지만 길어요!
그뿐만이 아닙니다. 문제는 전달되는 매개변수입니다. 요소와 창의 모든 사전 설정된 가져오기/설정 속성에 대해 래퍼를 작성하거나 각 래퍼가 사용자 호출에서 전체 매개변수 목록을 받아들이는 두 가지 방법이 있습니다. 이는 매우 불편합니다. 그리고 가장 중요한 것은 설명하기 어렵다는 점입니다.
탈출구가 있으며 간단합니다. 바로 추상 속성 그룹입니다. 사용자 프로그램과 엔진 측면에서 동시에 볼 수 있는 전역 변수입니다.
작동 방식은 다음과 같습니다:
1. 요소와 윈도우의 모든 래퍼는 중앙 함수를 다루고 해당 인덱스를 전달합니다. 이 함수는 이를 사용하여 호출의 대상 요소/창을 결정합니다.
2. 이 호출 후 사용자는 선택한 추상 속성 집합을 필요한 값으로 설정합니다.
3. 중앙 함수를 호출하고 c.word "Set"을 전달합니다.
4. Central은 전역 변수의 추상 속성 값을 특정 요소 또는 창의 대상 속성으로 설정합니다.
5. 5. 요소/창을 업데이트하고 추상 속성을 0으로 재설정합니다.
그게 다입니다.
제 생각에는 간단하고 효율적인 솔루션이 다음과 같은 이점을 제공합니다:
a) 엄격한 일관성이 필요한 함수에 매개 변수를 전달하지 않고도 모든 요소 및 창의 속성에 쉽게 액세스할 수 있습니다. (플러스 - 전달 된 매개 변수 수에 대한 제한. 그리고 통화는 길고 읽을 수없는 것으로 판명되었습니다).
c)프로그램 어디에서나값을 설정 / 수신 할 때 요소 및 창의 속성 집합을 자유롭게 조합 할 수 있습니다.
단점을 발견하는 사람이 있다면 말씀해 주세요. 출시 전에 이 문제를 조율하면 좋을 것 같습니다.
Nikolai Semko CCanvas 클래스의 Update 함수에 정적 카운터를 넣고(사용하는 경우) 카운트%100 == 0과 같은 경우 이 카운터를 인쇄합니다.
니콜라스, 우리가 여러 개의 GUI 창에 대해 이야기하고 있다는 점을 고려할 가치가 있습니다. 마지막 릴리스에는 17 개가있었습니다. 각 요소에는 수백 개의 요소가 있습니다. 그리고 각 요소는 복잡합니다. 일련의 부품으로 구성됩니다. 각 세부 사항은 필요한 값으로 채우기 위해 올바른 위치에 통과해야하는 캔버스의 섹션입니다.
평균 창 10 개 (Papkov는 11 개의 창으로 구성된 인터페이스를 주문했습니다)의 평균 수를 취하고 각각에 요소 또는 테이블 세트가 있다고 상상하면 전체 인터페이스의 전체 렌더링에 많은 시간이 걸리는 이유가 분명해집니다. 인터페이스에는 아이콘, 그림자, 표면 그라데이션, 다양한 프레임이 있음을 상기시켜 드리겠습니다.... 모든 인터페이스의 전체 그림을 완성하는 데 총 500ms 이상이 걸립니다. 그것에 대해 할 수있는 일은 없습니다.
창 수를 줄이거나 그래픽을 단순화하면 더 빨라질 수 있습니다.
다시 그리기에 대해 - 순수한 ChartRedraw() 호출이 거의 없습니다. ChartRedraw 플래그는 모든 곳에서 사용됩니다. 이 플래그가 설정되면 25ms 후 다음 타이머 반복에서 ChartRedraw() 함수가 호출됩니다. 즉, 한 번만 호출됩니다. 이렇게 하면 불필요한 다시 그리기를 피할 수 있습니다. 아주 드문 경우에만 ChartRedraw() 를 직접 호출합니다.
데모 프로젝트 1.mqh 파일로 이동하여 모든 창을 OOI 플래그로 설정했습니다. (초기화 시 열림).
크기와 내용이 다른 총 15개의 창. 스크롤 막대와 표가 있는 2개의 창(캔버스가 부분적으로 숨겨져 있고 실제로는 2~3배 더 깁니다. 전체 길이는 슬라이더와 스크롤 막대의 비율로 판단할 수 있습니다). 총 그리기 영역(최소) 2000*1000픽셀. 하지만 그 이상이라고 생각합니다. 총 그려진 1158 부분 (코어 인쇄 후 확인). 모든 캔버스를 0에서 1600 -에서 1900ms까지 완전히 그리는 시간.
다시 한 번 그려야 했던 디테일의 양에 주목하세요. 그림자, 아이콘, 그라디언트, 프레임, 텍스트.
hini #: 특정 창이 열려 있을 때만 그릴 수 있나요? 수십 개의 창이 동시에 열려 있는 경우는 드뭅니다. 그럴 필요는 없습니다.
그런 일은 거의 없습니다. 저는 모든 인터페이스 창을 한꺼번에 여는 첫 번째 그림에 대해서만 이야기하고 있습니다. 첫 번째 그림이 가장 시간이 많이 걸립니다. 그 후에는 모든 이미지가 이미 저장되어 있고 필요한 경우 메모리에서 검색됩니다. 한 번의 호출로 몇 밀리초 만에 캔버스에 첨부됩니다. 이것은 문제가되지 않습니다. 첫 번째 그림의 시간을 압축하고 싶을 뿐입니다.
또한 전체 화면 캔버스는 변경할 때마다 완전히 다시 그리지만 50ms 이상 걸리지 않습니다....
가장 비싼 것은 텍스트를 그리는 것입니다. 따라서 매번 TextOut을 사용하지 않기 위해 배열에 저장합니다. 훨씬 더 빠릅니다.
이제 주요 과제는 사용자가 인터페이스 컨트롤을 프로그래밍 방식으로 제어할 수 있도록 하는 것입니다.
사용자 프로그램과 엔진의 공생 조합에서 그래픽 코어는 양 당사자의 알고리즘에 대해 글로벌 수준에서 볼 수 있기 때문에 기술적으로이 작업은 어렵지 않습니다. 문제는 사용자가 커널로 작업하는 방법을 모른다는 것입니다. 그는 요소 관리의 원리를 모르고 이해하지 못합니다. 따라서 커널에 액세스하고 값을 변경할 수있는 기능인 친숙한 래퍼를 제공해야합니다.
그러나 뉘앙스가 있습니다. 함수 이름이 너무 깁니다. 결국 대화형 요소의 각 기능 래퍼에는 요소와 창의 이름이 포함되어야 합니다. 이는 이름 사이의 방향성을 위해 필요합니다. 그렇지 않으면 사용자가 쉽게 혼동하고 함수 래퍼를 이해하지 못할 것입니다. 또한 이름이 일치 할 수 있으며 이것은 전혀 좋지 않습니다. 따라서 요소의 이름과 창의 이름이라는 두 가지 구성 요소에서 이름을 생성해야합니다. 그러면 혼동은 없지만 래퍼의 이름이 너무 길어집니다. 특히 전달된 매개 변수의 측면에서. 또한 함수에 접두사를 추가하여 인텔리센스를 통해 빠르게 찾을 수 있도록 해야 합니다. 이렇게 하면 팝업 샘플을 효율적으로 필터링할 수 있습니다. 편리합니다. 하지만 길어요!
그뿐만이 아닙니다. 문제는 전달되는 매개변수입니다. 요소와 창의 모든 사전 설정된 가져오기/설정 속성에 대해 래퍼를 작성하거나 각 래퍼가 사용자 호출에서 전체 매개변수 목록을 받아들이는 두 가지 방법이 있습니다. 이는 매우 불편합니다. 그리고 가장 중요한 것은 설명하기 어렵다는 점입니다.
탈출구가 있으며 간단합니다. 바로 추상 속성 그룹입니다. 사용자 프로그램과 엔진 측면에서 동시에 볼 수 있는 전역 변수입니다.
작동 방식은 다음과 같습니다:
1. 요소와 윈도우의 모든 래퍼는 중앙 함수를 다루고 해당 인덱스를 전달합니다. 이 함수는 이를 사용하여 호출의 대상 요소/창을 결정합니다.
2. 이 호출 후 사용자는 선택한 추상 속성 집합을 필요한 값으로 설정합니다.
3. 중앙 함수를 호출하고 c.word "Set"을 전달합니다.
4. Central은 전역 변수의 추상 속성 값을 특정 요소 또는 창의 대상 속성으로 설정합니다.
5. 5. 요소/창을 업데이트하고 추상 속성을 0으로 재설정합니다.
그게 다입니다.
제 생각에는 간단하고 효율적인 솔루션이 다음과 같은 이점을 제공합니다:
a) 엄격한 일관성이 필요한 함수에 매개 변수를 전달하지 않고도 모든 요소 및 창의 속성에 쉽게 액세스할 수 있습니다. (플러스 - 전달 된 매개 변수 수에 대한 제한. 그리고 통화는 길고 읽을 수없는 것으로 판명되었습니다).
c) 프로그램 어디에서나값을 설정 / 수신 할 때 요소 및 창의 속성 집합을 자유롭게 조합 할 수 있습니다.
단점을 발견하는 사람이 있다면 말씀해 주세요. 출시 전에 이 문제를 조율하면 좋을 것 같습니다.
니콜라스, 우리가 여러 개의 GUI 창에 대해 이야기하고 있다는 점을 고려할 가치가 있습니다. 마지막 릴리스에는 17 개가있었습니다. 각 요소에는 수백 개의 요소가 있습니다. 그리고 각 요소는 복잡합니다. 일련의 부품으로 구성됩니다. 각 세부 사항은 필요한 값으로 채우기 위해 올바른 위치에 통과해야하는 캔버스의 섹션입니다.
평균 창 10 개 (Papkov는 11 개의 창으로 구성된 인터페이스를 주문했습니다)의 평균 수를 취하고 각각에 요소 또는 테이블 세트가 있다고 상상하면 전체 인터페이스의 전체 렌더링에 많은 시간이 걸리는 이유가 분명해집니다. 인터페이스에는 아이콘, 그림자, 표면 그라데이션, 다양한 프레임이 있음을 상기시켜 드리겠습니다.... 모든 인터페이스의 전체 그림을 완성하는 데 총 500ms 이상이 걸립니다. 그것에 대해 할 수있는 일은 없습니다.
창 수를 줄이거나 그래픽을 단순화하면 더 빨라질 수 있습니다.
다시 그리기에 대해 - 순수한 ChartRedraw() 호출이 거의 없습니다. ChartRedraw 플래그는 모든 곳에서 사용됩니다. 이 플래그가 설정되면 25ms 후 다음 타이머 반복에서 ChartRedraw() 함수가 호출됩니다. 즉, 한 번만 호출됩니다. 이렇게 하면 불필요한 다시 그리기를 피할 수 있습니다. 아주 드문 경우에만 ChartRedraw() 를 직접 호출합니다.
또한 변경할 때마다 전체 화면 캔버스가 완전히 다시 그려지지만 50ms 이상 걸리지 않습니다...
가장 비싼 것은 텍스트를 그리는 것입니다. 따라서 매번 TextOut을 사용하지 않으려면 배열에 저장합니다. 훨씬 더 빠릅니다.
음, 여기서 간단한 산술이 작동합니다. 10 ~ 17 개의 창 영역의 합이 전체 화면보다 훨씬 큽니다. 동의합니다. 그림자, 아이콘, 프레임을 만드는 데 필요한 보조 추가 그림....
그리고 TextOut에 대해 확인하고 작성하겠습니다. 흥미로운 아이디어입니다.
테스트를 수행했습니다:
데모 프로젝트 1.mqh 파일로 이동하여 모든 창을 OOI 플래그로 설정했습니다. (초기화 시 열림).
크기와 내용이 다른 총 15개의 창. 스크롤 막대와 표가 있는 2개의 창(캔버스가 부분적으로 숨겨져 있고 실제로는 2~3배 더 깁니다. 전체 길이는 슬라이더와 스크롤 막대의 비율로 판단할 수 있습니다). 총 그리기 영역(최소) 2000*1000픽셀. 하지만 그 이상이라고 생각합니다. 총 그려진 1158 부분 (코어 인쇄 후 확인). 모든 캔버스를 0에서 1600 -에서 1900ms까지 완전히 그리는 시간.
다시 한 번 그려야 했던 디테일의 양에 주목하세요. 그림자, 아이콘, 그라디언트, 프레임, 텍스트.
그리기 시간은 스크린샷에 나와 있습니다:
특정 창이 열려 있을 때만 그릴 수 있나요? 수십 개의 창이 동시에 열려 있는 경우는 드뭅니다. 그럴 필요는 없습니다.
그런 일은 거의 없습니다. 저는 모든 인터페이스 창을 한꺼번에 여는 첫 번째 그림에 대해서만 이야기하고 있습니다. 첫 번째 그림이 가장 시간이 많이 걸립니다. 그 후에는 모든 이미지가 이미 저장되어 있고 필요한 경우 메모리에서 검색됩니다. 한 번의 호출로 몇 밀리초 만에 캔버스에 첨부됩니다. 이것은 문제가되지 않습니다. 첫 번째 그림의 시간을 압축하고 싶을 뿐입니다.
그리기 속도를 높일 수 있는 방법이 있을 수 있습니다. 창 플랫폼의 하단 바닥을 제거합니다. 이들은 요소가있는 앞면 뒤에있는 큰 캔버스입니다. 제거하면 속도가 두 배 빨라집니다. 생각해 봐야겠습니다.
이것이 제가 말하는 캔버스입니다:
1. 요소가 있는 앞면:
2. 창의 버튼(십자, 미니멀), 아이콘 및 이름 텍스트가 있는 뒷면. 그러나 전체 창이 녹색으로 표시되고 시간이 소요되었습니다. 그러나 사용자는 프레임과 창 헤더만 볼 수 있습니다. 이 곳에서 그림은 헛된 것으로 밝혀졌습니다: