추신. 그러나 프로세서가 다시 그리기를 로드하고 있을 수 있습니다. 즉, 픽셀 배열 내부를 그리는 것입니다. 즉, 높은(16ms) 타이머 주파수에서 발생하는 값 으로 어레이를 지속적으로 초기화합니다 .
아니요, 다시 그리기는 어떤 식으로든 프로세서를 로드하지 않습니다. 그래픽 드라이버에 명령을 보내는 것은 몇 나노 또는 최대 마이크로초의 문제이기 때문입니다. 비디오 메모리에 픽셀 단위로 그리는 것은 비디오 카드의 프로세서에 의해 수행되며 일반적으로 수백 개가 있으며 프로세서와 병렬로 동시에 작동합니다. 즉, 프로세서는 그래픽 드라이버에 명령을 제공합니다. CopyPut 모드에서 화면 좌표 Xc, Yc에 반지름 R이 있는 원을 표시합니다. 프로세서의 경우 매개변수 전달이 포함된 함수 호출일 뿐입니다. 그는 이것보다 더 나아가지 않습니다. 그는 그러한 호출을 더 이상 자주하지 않습니다(예: 초당 2번). 그렇지 않으면 사용자는 단순히 화면에서 아무 것도 만들지 않을 것이며 그렇게 자주 당길 수 없습니다. 열린 거래 목록을 보려면 한 시간, 하루 또는 그 이상이 걸릴 수 있습니다.
그리고 픽셀 단위 색상 지정의 알고리즘(예: Google "Bresenham's Algorithm")은 비디오 카드에 의해 수행되며 프로세서는 이에 머뭇거리지 않습니다. 또한 매우 빠르게 수행됩니다. 그리고.. 도전 당 한 번. 16ms의 주파수로 다시 초기화할 필요가 없으며, 프로세서 명령에 의해 새로운 변경이 이루어질 때까지 화면 이미지가 비디오 메모리에 일정하게 유지됩니다. 또한 화면의 눈에 보이는 반응 속도를 높이기 위해 비디오 메모리는 여전히 중복으로 유지되고 보이지 않는 항목은 변경되며 그 후에는 비디오 페이지가 즉시 전환됩니다.
그러나 귀하가 설명한 픽셀의 "일정한 배열 초기화 "를 표시하는 접근 방식에서 제거해야 하는 경우 이것이 요점이 아닙니다.
아니요, 다시 그리기는 어떤 식으로든 프로세서를 로드하지 않습니다. 그래픽 드라이버에 명령을 보내는 것은 몇 나노 또는 최대 마이크로초의 문제이기 때문입니다. 비디오 메모리에 픽셀 단위로 그리는 것은 비디오 카드의 프로세서에 의해 수행되며 일반적으로 수백 개가 있으며 프로세서와 병렬로 동시에 작동합니다. 즉, 프로세서는 그래픽 드라이버에 명령을 제공합니다. CopyPut 모드에서 화면 좌표 Xc, Yc에 반지름 R이 있는 원을 표시합니다. 프로세서의 경우 매개변수 전달이 포함된 함수 호출일 뿐입니다. 그는 이것보다 더 나아가지 않습니다. 그는 그러한 호출을 더 이상 자주하지 않습니다(예: 초당 2번). 그렇지 않으면 사용자는 단순히 화면에서 아무 것도 만들지 않을 것이며 그렇게 자주 당길 수 없습니다. 열린 거래 목록의 경우 - 자신을 상상해보십시오. 한 시간 또는 하루 또는 그 이상이 걸릴 수 있습니다.
그리고 픽셀 단위 색상 지정의 알고리즘(예: Google "Bresenham's Algorithm")은 비디오 카드에 의해 수행되며 프로세서는 이에 머뭇거리지 않습니다. 또한 매우 빠르게 수행됩니다. 그리고.. 도전 당 한 번. 16ms의 주파수로 다시 초기화할 필요가 없으며, 프로세서 명령에 의해 새로운 변경이 이루어질 때까지 화면 이미지가 비디오 메모리에 일정하게 유지됩니다. 또한 화면의 눈에 보이는 반응 속도를 높이기 위해 비디오 메모리는 여전히 중복으로 유지되고 보이지 않는 항목은 변경되며 그 후에는 비디오 페이지가 즉시 전환됩니다.
그러나 귀하가 설명한 픽셀의 "일정한 배열 초기화 "를 표시하는 접근 방식에서 제거해야 하는 경우 이것이 요점이 아닙니다.
아니요, 다시 그리기는 어떤 식으로든 프로세서를 로드하지 않습니다. 그래픽 드라이버에 명령을 보내는 것은 몇 나노 또는 최대 마이크로초의 문제이기 때문입니다. 비디오 메모리에 픽셀 단위로 그리는 것은 비디오 카드의 프로세서에 의해 수행되며 일반적으로 수백 개가 있으며 프로세서와 병렬로 동시에 작동합니다. 즉, 프로세서는 그래픽 드라이버에 명령을 제공합니다. CopyPut 모드에서 화면 좌표 Xc, Yc에 반지름 R이 있는 원을 표시합니다. 프로세서의 경우 매개변수 전달이 포함된 함수 호출일 뿐입니다. 그는 이것보다 더 나아가지 않습니다. 그는 그러한 호출을 더 이상 자주하지 않습니다(예: 초당 2번). 그렇지 않으면 사용자는 단순히 화면에서 아무 것도 만들지 않을 것이며 그렇게 자주 당길 수 없습니다. 열린 거래 목록의 경우 - 자신을 상상해보십시오. 한 시간 또는 하루 또는 그 이상이 걸릴 수 있습니다.
그리고 픽셀 단위 색상 지정의 알고리즘(예: Google "Bresenham's Algorithm")은 비디오 카드에 의해 수행되며 프로세서는 이에 머뭇거리지 않습니다. 또한 매우 빠르게 수행됩니다. 그리고.. 도전 당 한 번. 16ms의 주파수로 다시 초기화할 필요가 없으며, 프로세서 명령에 의해 새로운 변경이 이루어질 때까지 화면 이미지가 비디오 메모리에 일정하게 유지됩니다. 또한 화면의 눈에 보이는 반응 속도를 높이기 위해 비디오 메모리는 여전히 중복으로 유지되고 보이지 않는 항목은 변경되며 그 후에는 비디오 페이지가 즉시 전환됩니다.
그러나 귀하가 설명한 픽셀의 "일정한 배열 초기화 "를 표시하는 접근 방식에서 제거해야 하는 경우 이것이 요점이 아닙니다.
당신은 흥미로운 이론을 가지고 있습니다. 비록 그것이 내 실험의 결과와 완전히 일치하지는 않지만, 이제 아래에서 설명할 것입니다.
...
추신. 그러나 프로세서가 다시 그리기를 로드하고 있을 수 있습니다. 즉, 픽셀 배열 내부를 그리는 것입니다. 즉, 높은(16ms) 타이머 주파수에서 발생하는 값 으로 어레이를 지속적으로 초기화합니다 .
아니요, 다시 그리기는 어떤 식으로든 프로세서를 로드하지 않습니다. 그래픽 드라이버에 명령을 보내는 것은 몇 나노 또는 최대 마이크로초의 문제이기 때문입니다. 비디오 메모리에 픽셀 단위로 그리는 것은 비디오 카드의 프로세서에 의해 수행되며 일반적으로 수백 개가 있으며 프로세서와 병렬로 동시에 작동합니다. 즉, 프로세서는 그래픽 드라이버에 명령을 제공합니다. CopyPut 모드에서 화면 좌표 Xc, Yc에 반지름 R이 있는 원을 표시합니다. 프로세서의 경우 매개변수 전달이 포함된 함수 호출일 뿐입니다. 그는 이것보다 더 나아가지 않습니다. 그는 그러한 호출을 더 이상 자주하지 않습니다(예: 초당 2번). 그렇지 않으면 사용자는 단순히 화면에서 아무 것도 만들지 않을 것이며 그렇게 자주 당길 수 없습니다. 열린 거래 목록을 보려면 한 시간, 하루 또는 그 이상이 걸릴 수 있습니다.
그리고 픽셀 단위 색상 지정의 알고리즘(예: Google "Bresenham's Algorithm")은 비디오 카드에 의해 수행되며 프로세서는 이에 머뭇거리지 않습니다. 또한 매우 빠르게 수행됩니다. 그리고.. 도전 당 한 번. 16ms의 주파수로 다시 초기화할 필요가 없으며, 프로세서 명령에 의해 새로운 변경이 이루어질 때까지 화면 이미지가 비디오 메모리에 일정하게 유지됩니다. 또한 화면의 눈에 보이는 반응 속도를 높이기 위해 비디오 메모리는 여전히 중복으로 유지되고 보이지 않는 항목은 변경되며 그 후에는 비디오 페이지가 즉시 전환됩니다.
그러나 귀하가 설명한 픽셀의 "일정한 배열 초기화 "를 표시하는 접근 방식에서 제거해야 하는 경우 이것이 요점이 아닙니다.
보려면 클릭하세요.
그림에서 Open Time 열의 데이터에 문제가 있습니다.
아니요, 다시 그리기는 어떤 식으로든 프로세서를 로드하지 않습니다. 그래픽 드라이버에 명령을 보내는 것은 몇 나노 또는 최대 마이크로초의 문제이기 때문입니다. 비디오 메모리에 픽셀 단위로 그리는 것은 비디오 카드의 프로세서에 의해 수행되며 일반적으로 수백 개가 있으며 프로세서와 병렬로 동시에 작동합니다. 즉, 프로세서는 그래픽 드라이버에 명령을 제공합니다. CopyPut 모드에서 화면 좌표 Xc, Yc에 반지름 R이 있는 원을 표시합니다. 프로세서의 경우 매개변수 전달이 포함된 함수 호출일 뿐입니다. 그는 이것보다 더 나아가지 않습니다. 그는 그러한 호출을 더 이상 자주하지 않습니다(예: 초당 2번). 그렇지 않으면 사용자는 단순히 화면에서 아무 것도 만들지 않을 것이며 그렇게 자주 당길 수 없습니다. 열린 거래 목록의 경우 - 자신을 상상해보십시오. 한 시간 또는 하루 또는 그 이상이 걸릴 수 있습니다.
그리고 픽셀 단위 색상 지정의 알고리즘(예: Google "Bresenham's Algorithm")은 비디오 카드에 의해 수행되며 프로세서는 이에 머뭇거리지 않습니다. 또한 매우 빠르게 수행됩니다. 그리고.. 도전 당 한 번. 16ms의 주파수로 다시 초기화할 필요가 없으며, 프로세서 명령에 의해 새로운 변경이 이루어질 때까지 화면 이미지가 비디오 메모리에 일정하게 유지됩니다. 또한 화면의 눈에 보이는 반응 속도를 높이기 위해 비디오 메모리는 여전히 중복으로 유지되고 보이지 않는 항목은 변경되며 그 후에는 비디오 페이지가 즉시 전환됩니다.
그러나 귀하가 설명한 픽셀의 "일정한 배열 초기화 "를 표시하는 접근 방식에서 제거해야 하는 경우 이것이 요점이 아닙니다.
글쎄, 그들은 보상을 ...
일종의 단편적인 지식의 뒤죽박죽...
결국 똑같지 않다...
아니요, 다시 그리기는 어떤 식으로든 프로세서를 로드하지 않습니다. 그래픽 드라이버에 명령을 보내는 것은 몇 나노 또는 최대 마이크로초의 문제이기 때문입니다. 비디오 메모리에 픽셀 단위로 그리는 것은 비디오 카드의 프로세서에 의해 수행되며 일반적으로 수백 개가 있으며 프로세서와 병렬로 동시에 작동합니다. 즉, 프로세서는 그래픽 드라이버에 명령을 제공합니다. CopyPut 모드에서 화면 좌표 Xc, Yc에 반지름 R이 있는 원을 표시합니다. 프로세서의 경우 매개변수 전달이 포함된 함수 호출일 뿐입니다. 그는 이것보다 더 나아가지 않습니다. 그는 그러한 호출을 더 이상 자주하지 않습니다(예: 초당 2번). 그렇지 않으면 사용자는 단순히 화면에서 아무 것도 만들지 않을 것이며 그렇게 자주 당길 수 없습니다. 열린 거래 목록의 경우 - 자신을 상상해보십시오. 한 시간 또는 하루 또는 그 이상이 걸릴 수 있습니다.
그리고 픽셀 단위 색상 지정의 알고리즘(예: Google "Bresenham's Algorithm")은 비디오 카드에 의해 수행되며 프로세서는 이에 머뭇거리지 않습니다. 또한 매우 빠르게 수행됩니다. 그리고.. 도전 당 한 번. 16ms의 주파수로 다시 초기화할 필요가 없으며, 프로세서 명령에 의해 새로운 변경이 이루어질 때까지 화면 이미지가 비디오 메모리에 일정하게 유지됩니다. 또한 화면의 눈에 보이는 반응 속도를 높이기 위해 비디오 메모리는 여전히 중복으로 유지되고 보이지 않는 항목은 변경되며 그 후에는 비디오 페이지가 즉시 전환됩니다.
그러나 귀하가 설명한 픽셀의 "일정한 배열 초기화 "를 표시하는 접근 방식에서 제거해야 하는 경우 이것이 요점이 아닙니다.
당신은 흥미로운 이론을 가지고 있습니다. 비록 그것이 내 실험의 결과와 완전히 일치하지는 않지만, 이제 아래에서 설명할 것입니다.
테스트에서 알 수 있듯이 프로세서를 가장 많이 로드하는 것은 픽셀 어레이의 초기화입니다.
아래에서 테스트 EA를 확인하세요.
나는 테스트 결과가 나를 조금 놀랐다는 것을 인정해야 한다.
그래서 우리는 16ms의 주파수에서 일정한 함수 호출에 대해 이야기하고 있습니다.
그릴 때 프로세서를 가장 많이 로드하는 것은 픽셀 어레이의 초기화 라는 것이 밝혀졌습니다.
그러나 가장 이상한 점은 주기적인 함수 호출이
프로세서에 10 - 15%를 로드합니다.
또한 전화를
동일한 10-15%에 부하.
동시에 세 가지 기능의 동시 호출
접히는 하중을 가하지 마십시오. 부하는 여전히 10-15%로 유지됩니다.
그러나 이러한 호출에 백만 셀의 배열을 다시 초기화하는 일정한 주기를 추가하면
그러면 프로세서의 부하가 최대 50%까지 증가합니다.
//------------------------------------------------ -------------------------------------------------- -------------------------------------------------- -
기능 자체
프로세서를 로드하지 않습니다.
기능
Arr[] 배열의 크기에 따라 0에서 5퍼센트까지 로드됩니다.
다음은 테스트 어드바이저입니다. 작업 관리자에서 행을 번갈아 주석 처리하고 프로세서 부하를 확인해야 합니다.
그의 코드는 다음과 같습니다.
그림에서 Open Time 열의 데이터에 문제가 있습니다.
네. 나는 TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);
이유를 모르겠습니다.
나는 테스트 결과가 나를 조금 놀랐다는 것을 인정해야 한다.
그래서 우리는 16ms의 주파수에서 일정한 함수 호출에 대해 이야기하고 있습니다.
그릴 때 프로세서를 가장 많이 로드하는 것은 픽셀 어레이의 초기화 라는 것이 밝혀졌습니다.
그러나 가장 이상한 점은 주기적인 함수 호출이
프로세서를 10 - 15% 로드합니다.
또한 전화를
동일한 10-15%에 부하.
동시에 세 가지 기능의 동시 호출
접히는 하중을 가하지 마십시오. 부하는 여전히 10-15%로 유지됩니다.
그러나 이러한 호출에 백만 셀의 배열을 다시 초기화하는 일정한 주기를 추가하면
그러면 프로세서의 부하가 최대 50%까지 증가합니다.
//------------------------------------------------ -------------------------------------------------- -------------------------------------------------- -
기능 자체
프로세서를 로드하지 않습니다.
기능
Arr[] 배열의 크기에 따라 0에서 5퍼센트까지 로드됩니다.
나는 테스트 결과가 나를 조금 놀랐다는 것을 인정해야 한다.
그래서 우리는 16ms의 주파수에서 일정한 함수 호출에 대해 이야기하고 있습니다.
그릴 때 프로세서를 가장 많이 로드하는 것은 픽셀 어레이의 초기화 라는 것이 밝혀졌습니다.
그러나 가장 이상한 점은 주기적인 함수 호출이
프로세서를 10 - 15% 로드합니다.
또한 전화를
동일한 10 - 15%에 부하.
동시에 세 가지 기능의 동시 호출
접히는 하중을 가하지 마십시오. 부하는 여전히 10-15%로 유지됩니다.
그러나 이러한 호출에 백만 셀의 배열을 다시 초기화하는 일정한 주기를 추가하면
그러면 프로세서의 부하가 최대 50%까지 증가합니다.
//------------------------------------------------ -------------------------------------------------- -------------------------------------------------- -
기능 자체
프로세서를 로드하지 않습니다.
기능
Arr[] 배열의 크기에 따라 0에서 5퍼센트까지 로드됩니다.
Peter, 수백 페이지 동안 당신에게 대답하는 어떤 것도 듣지 않는 그런 끈질긴 느낌.
주제 다시 읽기 - "왜 그렇게"라는 질문에 대한 답변이 있습니다.
네. 나는 TimeToStr(OrderOpenPrice(),TIME_MINUTES|TIME_SECONDS);
이유를 모르겠습니다.
OrderOpenPrice 대신 OrderOpenTime()을 넣어야 하기 때문에