오류, 버그, 질문 - 페이지 975

[[삭제]]

미안해, 내가 틀렸어. 비트맵 성능은 레이블보다 16%-25% 열등 하지만(요소 수에 따라 다름) 이전에 썼던 것처럼 몇 배는 아닙니다.

아마도 도구를 처음 마스터했을 때 코드에 오류/비효율이 있었을 것입니다.

코드를 첨부합니다.

톨64

나를 믿으십시오, 나는 당신을 속일 단 하나의 동기도 없습니다 = 나 자신. 첫 번째 실험에서는 테스터에서 비트맵을 관찰했습니다. 불행히도 재생산할 수 없습니다. :(

[Anatoli Kazharski]

voix_kas :

...

톨64

나를 믿으십시오, 나는 당신을 속일 단 하나의 동기도 없습니다 = 나 자신. 첫 번째 실험에서는 테스터에서 비트맵을 관찰했습니다. 불행히도 재생산할 수 없습니다. :(

확인. 개발자가 이 기능을 구현한 다음 제대로 테스트하기를 기다리고 있습니다. )))

[[삭제]]

또한 글꼴 표시의 차이점에 대해 개발자의 관심을 끌고 싶습니다.

왼쪽 - 비트맵, 오른쪽 - 레이블. 비트맵은 모든 설정이 동일하지만 글꼴 렌더링이 약간 더 굵습니다.

질문은 중요하지 않습니다. 그러나 질서를 위해서는주의를 기울여야합니다. :)

[Anatoli Kazharski]

voix_kas :

또한 글꼴 표시의 차이점에 대해 개발자의 관심을 끌고 싶습니다.

왼쪽 - 비트맵, 오른쪽 - 레이블. 비트맵은 모든 설정이 동일하지만 글꼴 렌더링이 약간 더 굵습니다.

질문은 중요하지 않습니다. 그러나 질서를 위해서는주의를 기울여야합니다. :)

그리고 비트맵 의 글꼴 두께를 설정하는 데 사용한 플래그는 무엇입니까?

[---]

voix_kas :

미안해, 내가 틀렸어. 비트맵 성능은 레이블보다 16%-25% 열등 하지만(요소 수에 따라 다름) 이전에 썼던 것처럼 몇 배는 아닙니다.

아니요. 당신의 테스트는 여전히 잘못되었습니다.

모든 변경 후에 ChartRedraw를 사용 합니다. 즉, 실제로 ChartRedraw를 10000번 테스트하고 있습니다. 이것은 사실이 아닙니다.

결국 작업은 레이블 또는 비트맵 중 무엇을 더 빠르게 수정하는지 찾는 것입니다. 그리고 차트에 대한 후속 항목이 아닙니다.

다음은 ChartRedraw를 루프 안에 두면 테스트 결과입니다.

비트맵 업데이트 시간=40980.
레이블 업데이트 시간 = 41777.

(즉, 비트맵이 레이블보다 조금 더 빠름)

그리고 루프 내부 에 ChartRedraw가 있는 경우 레이블 수와 비트맵 너비에 따라 달라지는 것은 없습니다 . 즉, ChartRedraw 함수는 이 상황에서 가장 느립니다.

---

루프에서 ChartRedraw를 제거하면 완전히 다른 숫자를 얻습니다.

비트맵 업데이트 시간=5788.
레이블 업데이트 시간 = 234.

즉, 레이블이 있는 터미널은 비트맵보다 20 배 빠르게 작동합니다.

물론 여기에서 이미 비트맵 높이의 의존성을 볼 수 있습니다. 100개의 태그에 대해:

비트맵 업데이트 시간=51355.
레이블 업데이트 시간 = 1108.
50 배 차이

250 * 20 크기의 비트맵이 있습니다. 즉, 마크의 좌표를 변경하지 않습니다. 한 지점에서 전체 100개의 출력만 가능합니다.

우리는 얻는다

비트맵 업데이트 시간=25054.

100마르크의 차이는 25배입니다.

즉, 보시다시피 비트맵은 그녀와 작업할 때 정말 느린 사람입니다. 그리는 과정이 느립니다.

arrays + WinGdi TextOut + ResourceCreate = Creations를 사용한 지속적인 순환 작업이 기본 MT 개체보다 최소 10배, 심지어 50배까지 열등하다는 것은 분명합니다 .

따라서 어떤 식으로든 MT 개체를 거부하는 것은 불가능합니다. 그러나 비트맵도 빼놓을 수 없습니다. 그래프와 히스토그램을 그리는 데 매우 편리할 것이기 때문입니다.

[[삭제]]

tol64 :
그리고 비트맵 의 글꼴 두께를 설정하는 데 사용한 플래그는 무엇입니까?

기본값은 0이며 명시적으로 설정하지 않았습니다. 첨부된 소스코드에서 확인하실 수 있습니다.

플래그가 다른 추가 "게임"도 획일화로 이어지지 않았습니다.

[[삭제]]

sergeev :

...

결국 작업은 레이블 또는 비트맵 중 무엇을 더 빠르게 수정하는지 찾는 것입니다. 그리고 차트에 대한 후속 항목이 아닙니다.

...

루프에서 ChartRedraw() 함수를 제거하는 것은 올바르지 않습니다. 텍스트 레이블 속성을 변경하는 "원자적 작업"이 터미널의 비디오 엔진에서 어떤 식으로든 처리되지 않기 때문입니다.

ChartRedraw()가 호출될 때만 다른 개체의 알파 채널이 있는 이미지의 상호 오버레이를 포함하여 전체 창이 그려집니다.

이 가설은 텍스트 레이블이 있는 스크립트의 코드 프로파일러에 의해 강력하게 확인됩니다.

비트맵의 병목 현상은 TextOut() 함수입니다.

[Anatoli Kazharski]

voix_kas :

...

비트맵의 병목 현상은 TextOut() 함수입니다.

이렇게 하면 더 멋져보입니다 :)

[[삭제]]

tol64 :

이렇게 하면 더 멋져보입니다 :)

동의한다. :)

세르게예프 :

...

다음은 ChartRedraw를 루프 안에 두면 테스트 결과입니다.

비트맵 업데이트 시간=40980.
레이블 업데이트 시간 = 41777.

(즉, 비트맵은 레이블보다 약간 빠름)

이상하게도 반대 그림이 있습니다.

[Renat Fatkhullin]

추가 색상 정규화 오버헤드가 발생하므로 Argb_normalize를 사용하면 안 됩니다. 단순한 것을 순수한 색으로 칠하는 것이 좋습니다.

비디오 카드는 우리가 2D 기능을 Might와 Main과 함께 사용하기 때문에 속도에 직접적이고 강하게 영향을 미칩니다. 예를 들어, 비디오 카드가 가장 단순한 약한 노트북에서는 렌더링 이 느리고 출력 방식의 차이가 큽니다.