니콜라이, 이제" 캔버스를그리는 데 왜 그렇게 오래 걸리는가"라는 질문에 대한 답이 예기치 않게 나왔습니다.
창은 두 개의 캔버스로 구성되어 있습니다 ! 이 캔버스는 크기가 거의 같습니다. 따라서 그리기 영역에 2를 곱해야 합니다. 하지만 이것은 시작에 불과합니다.
창 공간에는 원래 색상으로 완전히 채워진 큰 스크롤 요소(V_BOX)가 있습니다. 즉, V_BOX가 창의 주요 부분을 차지하는 경우 그리기 영역에 3을 곱해야합니다. 하지만! 추가 캔버스가 있습니다. 이미지가 해당 캔버스에서 스크롤됩니다. 요소의 바닥은 스크롤 막대일 뿐입니다. 요컨대 그리기 영역에 4를 곱해야합니다 (특히 스크롤 막대가 긴 경우). 그리고 나서야 요소가 그려집니다.
그것은 모든 것 같습니다 ... 우리는 포인트를 넣을 수 있습니다.창의 면적에 3 또는 4를 곱합니다. 그러나 아니오!
요소 자체도 다층적입니다. 각각에는 기본이 있습니다. 베이스는 항상 처음부터 그려지고 원래 색상으로 채워집니다. 그런 다음 프레임이 기본 위에 그려집니다. 다음으로 요소의 이미 그려진 부분 위에 아이콘이 그려집니다. 마지막으로 모든 요소 위에 텍스트가 그려집니다.
결과적으로 사용자는 각 특정 픽셀의 최종 색상만 볼 수 있습니다. 그러나 이 픽셀의 위치에서 전체 창이 그려질 때 색상이 여러 번 변경됩니다.
이제 여기에 15개의 창을 곱하세요.... 코드에 특별한 버그가 없다는 것이 분명해졌습니다. 드로잉 블록의 일부 실행 속도를 특별히 측정했으며 전체 화면의 경우 50ms도 저에게도 효과가 있습니다. 다만 화면이 더 많이 표시되는 것뿐입니다.
코드를 변경하고 그리기 속도를 2 ~ 3 배 높이는 방법에 대한 아이디어가 있습니다. 하지만 본 작업이 끝난 후에 할 것입니다.
코드 확인을 고집해 주셔서 감사합니다. 당신 말이 맞았어요. 비판이 도움이 된 경우입니다.
또한 텍스트에 대한 힌트를 주신 @AndreyBarinov에게도 감사드립니다. 제가 뭔가 생각해낼 수 있을지도 모르겠네요.
테스트는 대략적인 수치입니다. 거의 동일한 크기의 캔버스 세 개 (아이콘 창)로 창을 여는 속도를 측정 한 결과 ~ 70ms가 나왔습니다. 모든 캔버스(요소 제외)의 면적을 합하면 17인치 노트북 화면의 면적과 거의 비슷합니다. 여기에는 캔버스 위에 그려진 요소와 아이콘 자체의 바닥 면적은 포함되지 않습니다. 따라서 개념적인 전체 화면의 면적을 컬러로 채우는 데 50밀리초 정도 걸립니다. 아직 정확히 측정해 보지는 않았습니다. 왜, '코끼리'가 방 한가운데에 있는데? :)
코드를 변경하고 렌더링 속도를 2 ~ 3 배 높이는 방법에 대한 아이디어가 있습니다. 하지만 주요 작업 후에 할 것입니다 ...
작업의 복잡성과 최종 결과의 가치를 분석했습니다.
결론 : 그렇게하는 것은 의미가 없습니다.
첫 번째 그림의 속도를 높이는 것은 의미가 없습니다. 복잡한 그래픽과 스크롤 막대가 있는 15개의 창을 만드는 데 1초 30초가 걸리는 것은 정상적인 결과입니다. 첫 번째 그림은 창을 열기 전에 수행하여 사용자의 눈에서 숨길 수 있습니다. 시각적으로 창은 0.5 초 동안 일시 중지 된 후 즉시 나타납니다. 물론 한 번에 15개의 창이 열리기를 원한다면 그럴 가능성은 거의 없습니다.
창 뒷면을 그릴 필요는 없습니다. 약 20ms의 이득이 있을 것입니다. 인상적이지 않네요.
지난주에는 첫 번째 빌드를 제외한 모든 이벤트에서 저장된 이미지를 사용하는 것이 가장 큰 성과였습니다. 이는 인터페이스 속도가 크게 향상된 것입니다.
나머지 지연은 초점을 변경할 때 창을 다시 그리거나 불필요한 호출과 관련이 있습니다. 간단한 수정. 그다지 중요하지 않은 로딩 시간 때문에 이 큰 이득을 무시하고 싶지 않았습니다. 하지만 저는 제 자신의 관심의 초점을 옮겼습니다. 그랬어야 했죠.
여기서는 첫 번째 렌더링 속도에 대한 질문은 현재 개발과 무관하고 관련성이 없기 때문에 닫습니다.
일요일에 다음 업데이트. 사용자 프로그램과 소프트웨어 상호 작용의 개념적으로 완전한 메커니즘을 갖춘 엔진을 출시할 예정입니다.
복잡한 그래픽과 스크롤바가 있는 15개의 창을 1초 반 만에 만드는 것은 정상적인 결과입니다. 창을 열기 전에 첫 번째 그래픽을 그려서 사용자가 볼 수 없도록 할 수 있습니다. 시각적으로 창은 0.5초 일시 정지 후 즉시 나타납니다. 물론 사용자가 동시에 15개의 창을 열기를 원한다면 그럴 가능성은 거의 없습니다.
창 뒤쪽을 그릴 필요는 없습니다. 약 20ms의 이득이 있을 것입니다. 놀랍지 않나요?
지난주에는 첫 번째 빌드를 제외한 모든 이벤트에 저장된 이미지를 사용한다는 주요 목표를 달성했습니다. 이는 인터페이스의 속도를 크게 향상시킨 것입니다.
나머지 지연은 초점을 변경할 때 창을 다시 그리거나 불필요한 호출과 관련된 것이었습니다. 이 문제는 쉽게 해결할 수 있습니다. 그다지 중요하지 않은 로딩 시간 때문에 이 중대한 개선 사항을 무시하고 싶지는 않습니다. 그러나 저는 초점을 옮겼습니다. 다음이 있어야 합니다.
첫 번째 렌더링 속도 문제는 현재 개발과 관련이 없거나 중요하지 않기 때문에 여기서 끝냈습니다.
다음 업데이트는 일요일에 있을 예정입니다. 소프트웨어와 사용자 프로그램 간의 상호 작용 메커니즘이 개념적으로 완성된 엔진을 소개할 예정입니다.
니콜라이 셈코
니콜라이, 이제" 캔버스를그리는 데 왜 그렇게 오래 걸리는가"라는 질문에 대한 답이 예기치 않게 나왔습니다.
창은 두 개의 캔버스로 구성되어 있습니다 ! 이 캔버스는 크기가 거의 같습니다. 따라서 그리기 영역에 2를 곱해야 합니다. 하지만 이것은 시작에 불과합니다.
창 공간에는 원래 색상으로 완전히 채워진 큰 스크롤 요소(V_BOX)가 있습니다. 즉, V_BOX가 창의 주요 부분을 차지하는 경우 그리기 영역에 3을 곱해야합니다. 하지만! 추가 캔버스가 있습니다. 이미지가 해당 캔버스에서 스크롤됩니다. 요소의 바닥은 스크롤 막대일 뿐입니다. 요컨대 그리기 영역에 4를 곱해야합니다 (특히 스크롤 막대가 긴 경우). 그리고 나서야 요소가 그려집니다.
그것은 모든 것 같습니다 ... 우리는 포인트를 넣을 수 있습니다.창의 면적에 3 또는 4를 곱합니다. 그러나 아니오!
요소 자체도 다층적입니다. 각각에는 기본이 있습니다. 베이스는 항상 처음부터 그려지고 원래 색상으로 채워집니다. 그런 다음 프레임이 기본 위에 그려집니다. 다음으로 요소의 이미 그려진 부분 위에 아이콘이 그려집니다. 마지막으로 모든 요소 위에 텍스트가 그려집니다.
결과적으로 사용자는 각 특정 픽셀의 최종 색상만 볼 수 있습니다. 그러나 이 픽셀의 위치에서 전체 창이 그려질 때 색상이 여러 번 변경됩니다.
이제 여기에 15개의 창을 곱하세요.... 코드에 특별한 버그가 없다는 것이 분명해졌습니다. 드로잉 블록의 일부 실행 속도를 특별히 측정했으며 전체 화면의 경우 50ms도 저에게도 효과가 있습니다. 다만 화면이 더 많이 표시되는 것뿐입니다.
코드를 변경하고 그리기 속도를 2 ~ 3 배 높이는 방법에 대한 아이디어가 있습니다. 하지만 본 작업이 끝난 후에 할 것입니다.
코드 확인을 고집해 주셔서 감사합니다. 당신 말이 맞았어요. 비판이 도움이 된 경우입니다.
또한 텍스트에 대한 힌트를 주신 @AndreyBarinov에게도 감사드립니다. 제가 뭔가 생각해낼 수 있을지도 모르겠네요.
니콜라이 셈코
...그리고 50ms 전체 화면도 잘 작동합니다. ....
테스트는 대략적인 수치입니다. 거의 동일한 크기의 캔버스 세 개 (아이콘 창)로 창을 여는 속도를 측정 한 결과 ~ 70ms가 나왔습니다. 모든 캔버스(요소 제외)의 면적을 합하면 17인치 노트북 화면의 면적과 거의 비슷합니다. 여기에는 캔버스 위에 그려진 요소와 아이콘 자체의 바닥 면적은 포함되지 않습니다. 따라서 개념적인 전체 화면의 면적을 컬러로 채우는 데 50밀리초 정도 걸립니다. 아직 정확히 측정해 보지는 않았습니다. 왜, '코끼리'가 방 한가운데에 있는데? :)
과부하가 걸리고 최적화되지 않은 인터페이스라고 해서 50ms 정도라고 말씀드렸습니다. 3-10ms는 정상입니다.
당신은 감자밭에 가고 싶지 않은 스털리츠와 같습니다.
드로잉 블록 내의 주기에 대한 심층적인 연구가 필요합니다. 피상적인 프로파일링으로는 완전한 그림을 그릴 수 없습니다. 하지만 요점이 무엇인지는 이미 분명합니다. 여기에 쓴 글 #553
. 나는 내가 틀리지 않았다고 생각합니다.
(드로잉 블록의 초안 버전, 테스트에 사용)...
코드를 변경하고 렌더링 속도를 2 ~ 3 배 높이는 방법에 대한 아이디어가 있습니다. 하지만 주요 작업 후에 할 것입니다 ...
작업의 복잡성과 최종 결과물의 가치를 분석했습니다.
네, 완전한 기능을 갖춘 소프트웨어를 먼저 출시하는 것이 가장 중요합니다.