2012-06-12 31 views
6

मिंट लिनक्स 12 पर Qt4.8 का उपयोग करके, मैंने एक मॉडल की सामग्री दिखाने के लिए QTableView युक्त एक साधारण विंडो लागू की। मॉडल डेटा लगातार अद्यतन किया जाता है (लॉग संदेश) और dataChanged() संकेत नियमित आधार पर उत्सर्जित होता है (यानी हर 100ms)।QWidget अद्यतन घटनाएं लेकिन कोई दृश्य अपडेट

समस्या जो मैं देखता हूं वह तालिका पर दृश्य अपडेट को रोक रहा है।

मैंने विंडो पर एक ईवेंट फ़िल्टर स्थापित किया है जो updateRequest-प्रकार की घटनाओं की गणना करता है, जो विजेट पेंटेंट (बच्चे विजेट्स पर भी, यानी tableView) को ट्रिगर करना चाहिए। ये उनके बीच ~ 170ms के औसत समय और ~ 9 0 एमएमएस के मानक विचलन (जो अपेक्षाकृत बड़ा है, मुझे लगता है) के साथ आते हैं। हालांकि, माना गया दृश्य अद्यतन दर केवल दो या तीन बार एक सेकंड है और मुझे आश्चर्य है कि क्यों। ऐसा लगता है कि सभी updateRequest ईवेंट विजेट विचित्र को ट्रिगर नहीं करते हैं या विंडो सिस्टम दृश्य अपडेट निगलता है।

एक दूसरे परीक्षण के रूप में, मैंने खिड़की को repaint या update प्रत्येक 100ms पर कॉल करके खुद को अपडेट करने के लिए मजबूर किया। repaint का उपयोग करके, मैंने updateRequest-प्रकार की घटनाओं और अंतराल के मानक विचलन की कमी में इसी वृद्धि देखी; update के साथ, संख्या में वृद्धि नहीं हुई। हालांकि, दोनों मामलों में अनुमानित अद्यतन दर की केवल मामूली वृद्धि हुई थी।

इसके अलावा: क्या यह मापने के लिए एक अच्छी विधि है कि वास्तव में विजेट को paintEvent हैंडलर को अधिभारित किए बिना वास्तव में कितनी बार पुनर्निर्मित किया जाता है? शायद QTest से कुछ?


अद्यतन: मैं अपने घटना फिल्टर बढ़ाया भी paintEvent प्रकार की घटनाओं को पकड़ने के लिए। बनाम उनमें से केवल एक अंक संख्या है> 1000 updateRequest-प्रकार की घटनाएं।

उत्तर

1

आपको घटना प्रेषक के aboutToBlock() और awake() सिग्नल का वाद्ययंत्र करना चाहिए, और QElapsedTimer का उपयोग करके उनके बीच का समय मापना चाहिए। वर्तमान धागे के लिए इवेंट डिस्पैचर का उदाहरण स्थिर QAbstractEventDispatcher::instance() द्वारा वापस किया जाता है।

यदि ईवेंट लूप आपके टाइम मापन विंडो के बहुत छोटे हिस्से के लिए सोता है, तो इसका मतलब है कि जीयूआई थ्रेड में बहुत अधिक चीजें चल रही हैं। आखिरी दूसरे के दौरान, घटना लूप कितनी देर तक सोते हैं, इस बात की गिनती रख सकते हैं। यदि यह 10% से कम है, तो आप धीमे अपडेट और व्हाट्नॉट की अपेक्षा कर सकते हैं। याद रखें कि अद्यतन घटनाएं Qt::LowEventPriority के साथ पंक्तिबद्ध हैं। उन्हें मानक कतारबद्ध सिग्नल और लगभग सभी अन्य घटनाओं से छूट दी जाएगी।

+0

अच्छा विचार! मैं वर्तमान में परियोजना के अनुसार एक तंग कार्यक्रम पर हूं, इसलिए इसका परीक्षण करने में कुछ दिन लगेंगे। मुझे लगता है कि यह मुझे लोड का एक अच्छा अवलोकन देना चाहिए, लेकिन मुझे वास्तव में अद्यतन की आवश्यकता होती है जो मेरे विजेट तक पहुंचती है और वे अनुमानित अद्यतन दर की तुलना में बहुत करीब (औसत, दिमाग) आते हैं। – arne

+0

गिनती ठीक है, लेकिन यह आपको अंतर्निहित समस्या के बारे में कुछ नहीं बताती है।यह सिर्फ आपको बताता है कि कोई समस्या है, और ठीक है, आप स्पष्ट रूप से कोड की एक पंक्ति लिखने के बिना इसे नोटिस कर सकते हैं :) –

0

QApplication::compressEventQEvent::UpdateRequest छोड़ देता है, यदि पहले से ही एक अनप्रचारित है। इस प्रकार अगर घटना को त्याग दिया जाता है, तो पेंटिंग के बिना भी पेंट तुरंत लौट सकते हैं। यदि आप updateRequest ईवेंट compressEvent ओवरराइट करके छोड़ दिए गए हैं, तो आप जांच सकते हैं।

+0

मुझे संपीड़न के बारे में पता है, लेकिन यह मुख्य घटना लूप/क्यूप्लिकेशन में कहीं नहीं किया गया है? मैंने सोचा कि अगर एक अद्यतनRequest एक विजेट तक पहुंचता है, तो यह पहले से ही किया जाना चाहिए। – arne

+0

आप सही हैं, संपीड़न EventLoop में किया जाता है। मैंने गलत समझा, जहां आप घटनाओं की गिनती करते हैं। और हाँ, अगर घटना विजेट तक पहुंच जाती है, तो संपीड़न पहले ही हो चुका है। तो, मेरे जवाब को अनदेखा करें। – Stefan