Nikolai Semko #: 퍼스 없음, 여전히 너무 많습니다. 모든 텍스트, 그림자 등이 포함된 인터페이스가 느린 프로세서에서 최대 50ms에 달합니다.
버그를 찾아보세요.
프로파일링을 실행하세요. 어떤 기능이 95%의 시간을 잡아먹는지 확인하세요.
차트에 대한 바인딩이 없는데도 ChartGet 또는 XY 함수를 사용하고 있을 수 있습니다.
어쨌든 프로파일링을 실행하세요. 40초밖에 걸리지 않습니다.
네, 모든 것을 다시 확인해 보겠습니다. 하지만 그게 중요한 게 아니에요. 드로잉 블록은 단순히 그리기만 하는 게 아니에요. 그 안에는 들어오는 이벤트를 처리하는 논리적 미로가 있습니다. 무엇을 그리고 무엇을 그리지 않을지 결정하는 데 필요합니다. 이미지를 가져올 위치, 오버레이할 위치 및 방법을 선택합니다. 100개의 선으로 이루어진 단순한 그리기 기능이라면 할 말이 없을 것입니다. 그러나 이것은 모든 것을 그릴 수 있는 방대한 메커니즘입니다.
네, 다시 한 번 확인해 보겠습니다. 하지만 그게 중요한 게 아닙니다. 드로잉 블록은 단순히 그리기만 하는 것이 아닙니다. 그 안에는 들어오는 이벤트를 처리하는 논리적 미로가 있습니다. 무엇을 그리고 무엇을 그리지 않을지 결정하는 데 필요합니다. 이미지를 가져올 위치, 오버레이할 위치 및 방법을 선택합니다. 100개의 선으로 이루어진 단순한 그리기 기능이라면 할 말이 없을 것입니다. 하지만 이것은 모든 것이 그려지도록 하는 거대한 메커니즘입니다.
그 점을 고려할 가치가 있습니다.))
아니요, 올바르게 구현하면 이벤트 모델은 수천 개의 검사가 있더라도 마이크로초(100만 분의 1초) 이상 걸리지 않습니다.
버그를 찾아보세요.
그리고 방어적인 태도는 그만두세요! 아무도 여러분을 공격하는 것이 아니라 도와주려는 것뿐입니다.
저는 10만 개의 오브젝트에서 눈에 띄는 지연(300밀리초 이상)이 시작되고 가격 시간과 연동되어 있습니다.
hini #: 속도는 아마도 뒷전으로 밀려날 수 있으며, 속도 최적화는 단번에 할 수 있는 일이 아니므로 당장은 기능을 개선하는 것이 좋습니다.
코더가 속도를 개선하는 것은 언제나 좋은 일입니다. 그리고 일반적으로 저도 동의합니다. 합리적입니다. 개발에서 적절한 우선순위를 정하는 것은 매우 중요합니다. 특히 대규모 프로젝트에서는 더욱 그렇습니다. 저는 사용자에게 속도가 얼마나 중요한지 아는 것이 중요했습니다. 말하자면 피드백을 얻는 것이죠. 속도를 높이는 것 자체는 제 초기 계획에 포함되지 않았습니다. 사용자가 인터페이스를 볼 때 지연으로 인해 움찔하지 않기를 바랐을 뿐입니다. :)
저는 스톡 캔버스를 사용하지 않습니다:).
그리고 하나의 비트맵에 다중 창 인터페이스를 구현하는 것이 더 쉽다는 것을 알았습니다. 하지만 각자의 방식대로!
아아, 모든 경우에 그런 것은 아닙니다. 제 작업의 경우 제한된 비트맵 세트로 작업하는 것이 기술적으로 더 쉽습니다. 그리고 100 % 더 빠릅니다. 훨씬 빠릅니다.
그러나 다른 개발의 경우 다른 솔루션이 더 잘 작동하므로 예-각자에게 적합합니다. :)
퍼스 없음, 여전히 너무 많습니다. 모든 텍스트, 그림자 등이 포함된 인터페이스가 느린 프로세서에서 최대 50ms에 달합니다.
네, 모든 것을 다시 확인해 보겠습니다. 하지만 그게 중요한 게 아니에요. 드로잉 블록은 단순히 그리기만 하는 게 아니에요. 그 안에는 들어오는 이벤트를 처리하는 논리적 미로가 있습니다. 무엇을 그리고 무엇을 그리지 않을지 결정하는 데 필요합니다. 이미지를 가져올 위치, 오버레이할 위치 및 방법을 선택합니다. 100개의 선으로 이루어진 단순한 그리기 기능이라면 할 말이 없을 것입니다. 그러나 이것은 모든 것을 그릴 수 있는 방대한 메커니즘입니다.
그 점을 고려할 가치가 있습니다.))
저는 스톡 캔버스를 사용하지 않습니다:).
...
그리고 이것은 즐거운 놀라움입니다. :) 자기 개발은 항상 멋지다. 불완전하더라도.
C캔버스 클래스는 마음에 들지만(심지어 생성자 파일에 그 기능이 포함되어 있기도 합니다) 아직 사용하지는 않습니다. 핵심 단어는 "아직"입니다. 큰 계획이 있습니다. 앞으로요.
네, 다시 한 번 확인해 보겠습니다. 하지만 그게 중요한 게 아닙니다. 드로잉 블록은 단순히 그리기만 하는 것이 아닙니다. 그 안에는 들어오는 이벤트를 처리하는 논리적 미로가 있습니다. 무엇을 그리고 무엇을 그리지 않을지 결정하는 데 필요합니다. 이미지를 가져올 위치, 오버레이할 위치 및 방법을 선택합니다. 100개의 선으로 이루어진 단순한 그리기 기능이라면 할 말이 없을 것입니다. 하지만 이것은 모든 것이 그려지도록 하는 거대한 메커니즘입니다.
그 점을 고려할 가치가 있습니다.))
아니요, 올바르게 구현된 이벤트 모델은 수천 개의 검사가 있더라도 마이크로초(100만 분의 1초) 이상 걸리지 않습니다.
방어적인 태도 아니에요)))) 하하. 그냥 설명하는 거죠. ))
좋아요. 간단한 테스트부터 시작하겠습니다. 전체 화면 캔버스 하나를 하나의 색상으로 채우고 시간을 측정해 보겠습니다. 렌더링 함수를 측정하면 내 코드에 브레이크가 있는지 여부가 더 명확해질 것입니다. 있을지도 모르죠. 논쟁하는 게 아닙니다. 확인해 봐야겠어요.
방어적인 태도를 취하는 것이 아닙니다.) 하하. 그냥 설명하는 거예요. ))
좋아요. 간단한 테스트부터 시작하겠습니다. 전체 화면 캔버스 하나를 하나의 색상으로 채우고 시간을 측정하겠습니다. 렌더링 함수를 측정하면 내 코드에 브레이크가 있는지 여부가 더 명확해질 것입니다. 있을지도 모르죠. 논쟁하는 게 아닙니다. 확인해 봐야겠어요.
프로파일링 작업을 해본 적이 없으신 것 같아서요. 디버깅도 안 해보셨잖아요.
프로파일링 작업을 해본 적이 없으신 줄 알았는데요. 디버깅도 해본 적이 없으시죠?
속도는 아마도 뒷전으로 밀려날 수 있으며, 속도 최적화는 단번에 할 수 있는 일이 아니므로 당장은 기능을 개선하는 것이 좋습니다.