매초마다 10 개 이상의 아이템을 트리스트에 추가하는 애플리케이션이 있습니다. 이로 인해 컨트롤과 UI가 응답하지 않고 때로는 충분히 페인트 할 수 없기 때문에 많은 CPU가 소모됩니다.컨트롤 페인트 스팸 방지 (트리 뷰,리스트 뷰 컨트롤의 과중한 업데이트 중)
이러한 새 항목은 다른 스레드에서 들어 오니, 로컬 캐싱과 같은 일을하지 않는 한 .BeginUpdate()을 사용할 수 없습니다.
고정 된 간격으로 BeginUpdate() 및 EndUpdate를 수행하면 간격 사이에 도색되지 않은/비어 있음을 제어합니다.
이 문제를 해결하는 가장 좋은 해결책은 무엇입니까? 이론적 인 컨트롤에서는 어쨌든 자신의 캐싱을 가지기 때문에 캐싱은 나에게 어리석은 것처럼 들리므로, 컨트롤이 업데이트되지 않지만 무언가가 아닌 마지막 페인트 된 상태로 컨트롤을 남겨 둘 수있는 방법이 있어야합니다.
새로운 항목은 다른 스레드에서 왔기 때문에 Control.Invoke가 이미 필요하므로 배치 할 수도 있습니다. 따라서 대기열에있는 항목을 푸시하고 주 스레드에서 해당 대기열을 폴링 (아마 타이머 사용)하고 BeginUpdate/EndUpdate 블록에 항목 일괄 처리를 추가하십시오. 타이머 간격을 통해 응답 성을 구성 할 수 있습니다. 대기열을 잠 가야하지만 더 이상 호출 할 필요가 없습니다.
추가 사항을 제공하는 스레드가 여러 개있는 경우 어쨌든 컨트롤의 소유 스레드에 정렬되어야합니다.
마샬링 후 단일 배치 메커니즘을 구현하는 것이 간단합니다.
컨트롤의 캐싱이 특정 요구 사항을 중심으로 설계되지는 않습니다. (이러한 종류의 위젯 툴킷에서는 정상적인 동작이 아닙니다.) 따라서로드 및 응답 성 요구 사항에 맞는 캐시로 더 잘 수행 할 수 있습니다.
문제는 애플리케이션의 응답 성이 아닌 것 같습니다. 10 개 항목은 매우 집중적으로 들리지 않습니다 (매우 무거운 항목이 아닌 경우). 그러므로 문제가 발생하지 않아야합니다.
Application.DoEvents를 추가하면 예상대로 응용 프로그램이 응답하게됩니다. 문제는 완료되는 부하가 아니라 시간 경과에 따라 Windows 메시지를 처리하는 것입니다.
주 스레드를 호출하여 컨트롤에 항목을 추가해야하므로 DoEvents를 몇 초 동안 호출하는 데 아무런 문제가 없어야합니다. 이것은 대단히 효율적인 솔루션은 아니지만 책임 성의 부족을 해결할 것입니다.
doevents가 아닌 invoke를 사용하고 있습니다. –
예,하지만 귀하의 문제에 대한 이해는 응용 프로그램이 응답하지 않는 것이 었습니다. 내 생각 엔이 문제는로드가 아니라 메시지 처리 능력입니다. DoEvents를 추가하면 호출을 사용하는지 여부에 관계없이 응용 프로그램이 반응 형이 될 가능성이 높습니다. 10 초/초 동안 반응이없는 앱이 있다는 것은 이상한 것처럼 보이므로 CPU로드가 아니라 처리 시간이라고 추측합니다. – Tollo