Charts: प्रदर्शन में वृद्धि

एंड्रॉइड वर्जन में मूल प्रदर्शन अड़चन रेंडरिंग कोड के अंदर कई अतिरिक्त आबंटन (सरणियों के) थे। मेमोरी को रेंडरिंग कोड के अंदर @PhilJay ने उस कोड को एक बफ़र में स्थानांतरित कर दिया है जो कि पूर्व- सौंपता है।

मैंने प्रतिपादन गणनाओं को बफर कक्षाओं में स्थानांतरित नहीं करना चुना, लेकिन केवल आवश्यक स्मृति को उसी तरह पूर्व आवंटित करें - लेकिन प्रतिपादन कोड के समान लूप में प्रतिपादन गणनाएं हैं। इस तरह कोड को प्रबंधित करना कहीं अधिक आसान है।

इसके अलावा यह एक प्रदर्शन लाभ है कि अतिरिक्त कार्यों के अंदर प्रतिपादन गणना नहीं की जा रही है, और डेटा दो बार के बजाय केवल एक बार प्रतिपादन कोड के अंदर लूप किया जाता है।

Btw, स्विफ्ट प्रदर्शन में वैसे भी जावा से बेहतर FAR है, इसलिए आपने देखा होगा कि उन सरणियों को पूर्व-आवंटित किए बिना भी प्रदर्शन लाभ होता है।

इसे ग्राफिक रूप से समझाने के लिए, रेंडरिंग कोड में यही किया जा रहा है:

• [रेंडरिंग शुरू करें]
• डेटासेट पर लूप
• -- इस डेटासेट के बिंदुओं के लिए सरणी आवंटित करें -- अब दोनों प्लेटफार्मों में पूर्व -आवंटित
• -- प्रतिपादन के लिए अंक की गणना करें -- _Android संस्करण में बफ़र्स में ले जाया गया_
• - उन बिंदुओं को प्रस्तुत करें
• [प्रतिबद्ध प्रतिपादन]

यह भी ध्यान दें कि जावा में, सार (फ़ंक्शन, कक्षाएं, विरासत) एक महान मूल्य के साथ आते हैं। यह व्यर्थ नहीं है कि Google ने स्वयं एक महत्वपूर्ण सिफारिश लिखी है:

Be careful with code abstractions

Often, developers use abstractions simply as a "good programming practice," 
because abstractions can improve code flexibility and maintenance. 
However, abstractions come at a significant cost: 
    generally they require a fair amount more code that needs to be executed, 
requiring more time and more RAM for that code to be mapped into memory. 
So if your abstractions aren't supplying a significant benefit, you should avoid them.

इसे सारांशित करना:

• आप हजारों डेटा बिंदुओं के साथ काम करने में सहज हो सकते हैं!
• मैं फिल को बिंदु गणना को वापस ले जाने के लिए समझाने की कोशिश कर रहा हूं ताकि इसे बनाए रखने के लिए आसान बनाए रखा जा सके ;-)

आपके स्पष्टीकरण के लिए धन्यवाद डैनियल। मुझे यकीन नहीं है कि इससे क्या लेना है, हालांकि।
मैंने जो किया है, वह सबसे बुनियादी परियोजना है (नीचे कोड देखें) और प्रदर्शन Android संस्करण के साथ तुलनीय नहीं है, पूरी तरह से ईमानदार होने के करीब भी नहीं है। एक बार जब आप iPad Mini3 और iPhone6 ​​जैसे अधिकांश वर्तमान iOS उपकरणों पर भी अधिकतम मात्रा में डेटापॉइंट (पूरी तरह से ज़ूम आउट) प्रदर्शित करने के करीब पहुंच जाते हैं, तो एक हजार डेटापॉइंट्स का उपयोग करने से बड़े पैमाने पर फ़्रेमड्रॉप्स होते हैं। जैसा कि मैंने कहा, MPAndroidcharts बिना पसीना बहाए बहुत धीमे उपकरणों पर कई हज़ारों को रेंडर कर सकता है।

ओवरराइड func viewDidLoad () {
सुपर.व्यूडिडलोड ()

    lineChart = LineChartView(frame: view.frame);
    view.addSubview(lineChart);
    lineChart.backgroundColor = UIColor.whiteColor()
    lineChart.descriptionText = "Just a test"
    lineChart.leftAxis.enabled = false
    lineChart.legend.enabled = false

    setData(20)
}

func setData(range:Float) {

    var count = 1000;
    var xVals = Array<String>();

    for(var i = 0; i<count; i++) {
        xVals.append(String(i) + "");
    }

    var yVals = Array<ChartDataEntry>();

    for (var i = 0; i<count; i++) {
        var mult = range + 1
        var val:Float = Float(random()) * mult + 3;
        yVals.append(ChartDataEntry(value: val, xIndex: i));
    }

    var lineSet:LineChartDataSet = LineChartDataSet(yVals: yVals, label: " ");
    lineSet.drawCirclesEnabled = false;
    lineSet.drawValuesEnabled = false;

    var lineData:LineChartData = LineChartData(xVals: xVals, dataSet: lineSet);
    lineChart.data = lineData;
}

वैसे मैंने अभी तक प्रदर्शन के लिए सभी चार्ट का परीक्षण नहीं किया है - इसलिए मुझे इसे जल्द ही करने की आवश्यकता है।
बाधा शायद एक आवंटन है जिसे मैंने कहीं याद किया है ... मैं परीक्षण करूंगा और आपको बता दूंगा! :-)

बहुत बहुत धन्यवाद डेनियल। आगे देख रहे हैं कि आप इसमें से क्या निचोड़ सकते हैं। IOS पर MPAndroidCharts के लिए एक व्यवहार्य साथी होना बहुत अच्छा होगा।

खैर, मैंने LineChartRenderer के साथ थोड़ा खेला है (जो विशेष रूप से BarChartRenderer की तुलना में धीमा है) और इंस्ट्रूमेंट्स का कहना है कि CGContext का ड्रापाथ यहां अपराधी है।
मैंने इसके बजाय UIBezierPath का उपयोग करके इस समस्या को कम करने का प्रयास किया, लेकिन जैसे ही आप पथ पर स्ट्रोक() को कॉल करते हैं, प्रदर्शन वैसा ही होता है। इससे पहले, ड्राइंग प्रदर्शन बहुत अच्छा है, लेकिन पथ शुरू और अंत बिंदु के संबंध में भरा हुआ है, न कि हम एक सरल रेखा चार्ट के लिए क्या चाहते हैं।
उम्मीद है कि आपको इसका हल खोजने में थोड़ा और भाग्य मिला होगा।

मैं अभी इसका परीक्षण कर रहा हूं, और हां ऐसा लगता है कि वास्तविक CGContextStrokePath खराब प्रदर्शन से ग्रस्त है।
प्रमुख हिटरों में से एक धराशायी रेखा है। इसे अक्षम करते समय, प्रदर्शन ~ दोगुना हो जाता है। लेकिन यह अभी भी एक हजार अंकों के साथ खराब है।
कोरग्राफिक्स को तेज़ बनाने का तरीका जानने के लिए मैं ऐप्पल दस्तावेज़ों में कुछ पढ़ रहा हूं

हां, कोर ग्राफिक्स निश्चित रूप से धीमी गति से पथ प्रस्तुत कर रहा है। संकल्प के कारण ऐसा लगता है - नए Apple उपकरणों पर रिज़ॉल्यूशन बहुत अधिक है, जिसका अर्थ है रेंडर करने के लिए अधिक पिक्सेल।

मुझे लगता है कि सीजी जीपीयू के बजाय सीपीयू पर प्रतिपादन कर रहा है। शायद कोई इसे बदलने का तरीका जानता है?

सीजी निश्चित रूप से प्रतिपादन के लिए सीपीयू का उपयोग कर रहा है और जहां तक ​​​​मुझे पता है कि इसे बदलने का कोई तरीका नहीं है।
GPU प्रतिपादन का अर्थ होता है OpenGL का उपयोग, दुर्भाग्य से। बमर कि सीजी इतना धीमा है कि एंड्रॉइड इस सामान को सीपीयू पर कैसे प्रस्तुत करता है।

यह वास्तव में डिवाइस के सीपीयू हैं जो धीमे हैं। ज्यादातर मामलों में बहुत धीमा
सीपीयू एंड्रॉइड के साथ तेज सीपीयू की तुलना में आईओएस के साथ बेहतर अनुभव देता है।

लेकिन Apple ने उन मामलों के बारे में नहीं सोचा जहाँ एक इष्टतम OS नहीं है
इसे तेज रखने के लिए पर्याप्त है।

मुझे लगता है कि जब हम बहुत सारे बिंदुओं का उपयोग करते हैं तो हम एनिमेशन से बच सकते हैं - लेकिन
मैं अभी भी लाइन के प्रदर्शन में सुधार करने का एक तरीका खोजने की उम्मीद कर रहा हूं
आधारित चार्ट।

ऐसा लगता है कि विशेष रूप से पथ आरेखण प्रणाली धीमी है, और कब
मेटर और फ्लैटनेस के साथ खेलना, और धराशायी लाइनों को अक्षम करना और
एंटीएलियासिंग - प्रदर्शन 500-700 अंक के लिए काफी बेहतर हो जाता है
iPhone 6, लेकिन फिर भी 1000 . के साथ झटकेदार

UIBezierPath का उपयोग करने का अवसर हो सकता है। जैसा कि मैंने कहा, जैसे ही आप 'स्ट्रोक' नहीं कहते हैं, वह चीज़ पर्याप्त तेज़ है, जो अनिवार्य रूप से सिस्टम को बताती है कि पथ एक स्ट्रोक है और इसे प्रारंभ बिंदु से समापन बिंदु तक नहीं भरा जाना चाहिए। मुझे नहीं पता कि पृष्ठभूमि में उसके साथ क्या हो रहा है, लेकिन इससे पता चलता है कि ग्राफ़ ड्राइंग स्वयं ही समस्या नहीं है।

हालांकि, चूंकि मुझे लाइन चार्ट के लिए UIBezierPath का ठीक से उपयोग करने का कोई तरीका नहीं मिला, यह ग्रिड लाइनों के लिए एक व्यवहार्य उम्मीदवार हो सकता है क्योंकि कोई स्ट्रोक को कॉल किए बिना आकर्षित करने के लिए पथ को चकमा दे सकता है। भले ही यह एपीआई के दृष्टिकोण से 'गलत' है, लेकिन इसे बेहतर प्रदर्शन देना चाहिए।

UIBezierPath CGPath, CGContextDrawPath के चारों ओर केवल एक UIKit आवरण है,
आदि।
कुछ मामलों में देखा गया प्रदर्शन में अंतर इसके कारण है
UIBezierPath के गुणों के साथ पहले CG की स्थापना
एंटीएलियासिंग, मैटर लिमिट आदि।

वास्तव में इसका उपयोग करने का कोई कारण नहीं है जब आप जानते हैं कि कैसे उपयोग करना है
कोर ग्राफिक्स।

और हाँ, हमें "स्ट्रोक" कहने की ज़रूरत है, क्योंकि हम उस पथ को स्ट्रोक करना चाहते हैं ...
इसे भरने के लिए नहीं।
ज्यादातर मामलों में पथपाकर सिस्टम के लिए ठोस भरने की तुलना में कठिन होता है
रंग, क्योंकि इसे लाइनों की चौड़ाई का ध्यान रखने की जरूरत है, जुड़ता है
रेखाओं और जोड़ों के आकार के बीच।

शुक्र पर, अप्रैल 17, 2015 को 10:50 बजे, AlBirdie सूचनाएं @github.com ने लिखा:

UIBezierPath का उपयोग करने का अवसर हो सकता है। जैसा कि मैंने कहा, वह बात
जैसे ही आप 'स्ट्रोक' कहते हैं, जो अनिवार्य रूप से पर्याप्त रूप से तेज़ है
सिस्टम को बताता है कि पथ एक स्ट्रोक है और इसे से नहीं भरा जाना चाहिए
समापन बिंदु के लिए startpoint। मुझे नहीं पता कि इसमें क्या हो रहा है
पृष्ठभूमि, लेकिन इससे पता चलता है कि ग्राफ ड्राइंग स्वयं नहीं है
अपने आप में मुद्दा।

हालांकि, चूंकि मुझे UIBezierPath को ठीक से उपयोग करने का कोई तरीका नहीं मिला
लाइन चार्ट, यह एक के रूप में ग्रिड लाइनों के लिए एक व्यवहार्य उम्मीदवार हो सकता है
स्ट्रोक को बुलाए बिना पथ को चकमा दे सकता है भले ही वह
एपीआई के दृष्टिकोण से 'गलत', इसे बेहतर प्रदर्शन देना चाहिए।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -93937181
.

@danielgindi के बारे में आपने सोचा है कि यदि एनीमेशन चीजों को धीमा कर रहा है, तो एनीमेशन के बिना सभी लाइनों को कैसे खींचना है, और इसे कवर करने वाले मास्क दृश्य का उपयोग करें, तो एनीमेशन की नकल करने के लिए मुखौटा दृश्य को चेतन करें?

अच्छा यह एक अच्छा विचार है! :)

हालांकि एक नकारात्मक पहलू है:
यह उस तरह के एनिमेशन को पंगु बना देगा जो आप इसके साथ कर सकते हैं। जैसा कि हम अनुमति देते हैं
Y अक्ष को एनिमेट करते हुए चार्ट "बढ़ता" है, और जिस तरह से लाइन भरता है
एक्स अक्ष पर भी केवल एक स्ट्रोक होने पर अलग होता है।

कोशिश करने के लिए चीजों की मेरी सूची है:

1. किसी तरह कोरग्राफिक्स को बढ़ाएं या रेंडरिंग के हिस्से को ऊपर उठाएं
   जीपीयू
   
   
   
   1. सभी एनीमेशन फ़्रेमों को प्री-रेंडर करें- यह एनीमेशन शुरू करने में देरी करेगा, और
      
      काफी मात्रा में स्मृति का उपभोग करें
   
   
   2. आपका मास्किंग विचार- जो एनिमेशन के प्रकार को सीमित करता है
   
   

अगर अन्य विचार हैं तो मुझे उन्हें सुनना अच्छा लगेगा!

डैनियल, क्या आपने अभी तक GPU को काम करने की कोशिश की?
मैं वास्तव में, उस व्यावसायिक समाधान से वास्तव में नाखुश हूं, जिसके साथ हम वर्तमान में काम कर रहे हैं (भयानक एपीआई, भयानक रूप से बंद, और बहुत सारे बग जो ऐप को क्रैश कर देते हैं), और MPAndroidCharts के साथ इतनी बड़ी सफलता प्राप्त करने के बाद, हम स्विच करना पसंद करेंगे आईओएस-चार्ट अंततः अगर प्रदर्शन बराबर है। निश्चिंत रहें, आपके काम को पुरस्कृत किया जाएगा। ;)

कुछ अलग तकनीकों को आजमाते हुए, मैं आपको कुछ दिनों में एक अपडेट दूंगा!

सोम, 20 अप्रैल, 2015 को दोपहर 12:38 बजे, अलबर्डी नोटिफिकेशन @github.com ने लिखा:

डैनियल, क्या आपने अभी तक GPU को काम करने की कोशिश की?
मैं वास्तव में, वास्तव में हमारे द्वारा वर्तमान में किए जा रहे व्यावसायिक समाधान से नाखुश हूं
के साथ काम करना (भयानक एपीआई, विस्मयकारी रूप से बंद, और बग का कारण बनता है
ऐप क्रैश हो गया), और MPAndroidCharts के साथ इतनी बड़ी सफलता प्राप्त करने के बाद, हम
अगर प्रदर्शन बराबर है तो आईओएस-चार्ट पर स्विच करना पसंद है। आराम
सुनिश्चित करें, आपके काम को पुरस्कृत किया जाएगा। ;)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -94408574
.

@AlBirdie आप किस तरह के प्रदर्शन की अड़चन से मिले? मैं वर्तमान में एक उत्पाद का मालिक हूं जो आईओएस-चार्ट की तरह चार्ट खींचता है, हमारे पास पहले से ही एक चार्ट लाइब्रेरी आंतरिक रूप से थी। मुझे प्रदर्शन के बारे में भी चिंता है, वर्तमान में, हम केवल 100-1000 डेटा सेट लोड करते हैं, अब ठीक लगता है।

मैं भविष्य में यदि संभव हो तो आईओएस-चार्ट में बदलने पर भी विचार कर रहा हूं, लेकिन हमारे पुस्तकालय में इशारों में आईओएस-चार्ट के साथ संघर्ष हो सकता है।

प्रदर्शन की समस्या एनिमेशन में धीमी फ्रेम-दर है जब
एक रेखा चार्ट में 500-1000 रेखाएँ खींचना।

इशारों के संबंध में - हम मानक UIGestureRecognizers का उपयोग कर रहे हैं - जो आप
अक्षम, संशोधित या साथ काम कर सकता है। सब कुछ मानकीकृत है। :-)

सोम, 20 अप्रैल, 2015 को दोपहर 12:53 बजे, Xuan [email protected] ने लिखा:

@AlBirdie https://github.com/AlBirdie किस तरह का प्रदर्शन
बाधा तुम मिले? मेरे पास वर्तमान में एक ऐसे उत्पाद का स्वामित्व है जो चार्ट बनाता है
आईओएस-चार्ट की तरह, हमारे पास पहले से ही आंतरिक रूप से एक चार्ट लाइब्रेरी थी। मुझे भी चिंता है
प्रदर्शन के बारे में, वर्तमान में, हम केवल 100-1000 डेटा सेट लोड करते हैं, ठीक लगता है
अब क।

मैं भविष्य में यदि संभव हो तो आईओएस-चार्ट में बदलने पर भी विचार कर रहा हूं,
लेकिन हमारी लाइब्रेरी में जेस्चर थे जिनका आईओएस-चार्ट के साथ विरोध हो सकता है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/danielgindi/ios-charts/issues/29#issuecomment -94411060
.

@danielgindi ठीक है, मुझे लगता है कि हम एनिमेशन को दूर करने के लिए मास्क व्यू का उपयोग करते हैं ... हमारे लाइन चार्ट में ग्रेडिएंट लेयर है। आपके डेमो के रूप में, आपका एनीमेशन एक ही समय में X+Y दोनों दिशाओं को कर सकता है, जबकि हम केवल X दिशा करते हैं। मुझे यकीन नहीं है कि मास्क ट्रिक आपकी मदद कर सकती है।
मेरे मन में अब यह है कि अगर हमारे पास आपकी X + Y दिशा का वर्णन करने के लिए एक वेक्टर था, तो शायद मास्क चाल का उपयोग करने का एक मौका है ... आपके परिणामों के लिए तत्पर हैं!

@ liuxuan30 मुझे लगता है कि सामान्य धीमा प्रदर्शन। एनिमेशन कोई समस्या नहीं है क्योंकि मैं उनके साथ काम नहीं कर रहा हूं। मैं वित्त चार्ट पर काम कर रहा हूं जहां आपको एक चार्ट में एकाधिक डेटासेट (एकाधिक स्टॉक + संकेतकों की एक श्रृंखला) की आवश्यकता होती है। 250 आइटम्स की डेटा रेंज के लिए जो आसानी से कई हज़ार पॉइंट तक जोड़ देता है जिसे पैनिंग और पिंचिंग के दौरान एक बार में रेंडर करने की आवश्यकता होती है। जिस व्यावसायिक समाधान के साथ मैं वर्तमान में काम कर रहा हूं वह बहुत अच्छा है (ओपनजीएल का उपयोग करके आप सीपीयू को ओवरलोड किए बिना हजारों अंक प्रस्तुत कर सकते हैं), लेकिन मैं बंद स्रोत पुस्तकालयों का मित्र नहीं हूं जहां आपको बग फिक्स के लिए महीनों इंतजार करना पड़ता है।
मैं आईओएस-चार्ट के साथ और अधिक सहज महसूस करता हूं, खासकर जब एमपीएंड्रॉइड चार्ट के एपीआई के साथ काम करना अविश्वसनीय रूप से आसान है।

मैं देखता हूं, वित्त डेटा आपदा है। हमारा सर्वर मोबाइल डिवाइस पर केवल 1000 डेटा सेट भेजने के लिए बाध्य है, इसलिए हमारा अधिभार कम हो गया है। क्या आईओएस-चार्ट के लिए ओपनजीएल का उपयोग करने का कोई मौका है? @danielgindi

ओपनजीएल समर्थन इक्के होगा। एक GPU प्रदान किया गया लाइन चार्ट शायद अभी के लिए पर्याप्त होगा।
दुर्भाग्य से, मुझे ओपनजीएल के बारे में बिल्कुल पता नहीं है, अन्यथा मुझे मदद करने में खुशी होगी।

पथों का उपयोग करने के विरोध में CGContextStrokeLineSegments में सुधार हुआ है, इसलिए आपको यह प्रयास करना चाहिए।
अभी भी चीजों को सुधारने के अन्य तरीकों की कोशिश कर रहा है :-)

धन्यवाद डैनियल, मैं एक छोटा परीक्षण ऐप बनाउंगा जो एक दूसरे के खिलाफ दो संस्करणों को बेंच देता है यह देखने के लिए कि क्या है। नए लाइनसेगमेंट का उपयोग करके आपको क्या प्रदर्शन लाभ प्राप्त हुए?

@AlBirdie क्या आप लाइन सेगमेंट के साथ अंतर महसूस करते हैं?

इसके अलावा मुझे अभी एहसास हुआ है: एंड्रॉइड में अधिकतम प्रदर्शन प्राप्त करने के लिए आप इसे हार्डवेयर परत पर सेट करते हैं- जिस स्थिति में धराशायी रेखाएं धराशायी नहीं होती हैं, वे सभी ठोस होते हैं।

तो पहली बात अगर आप आईओएस पर धराशायी लाइनों को अक्षम करते हैं तो आपको भी महत्वपूर्ण बढ़ावा मिलता है!

लेकिन मुझे लगता है कि मैं वास्तव में सीआईएममेज पर ओपनजीएल ईएस का उपयोग करके इसे आकर्षित कर सकता हूं, लेकिन बहुत सावधान रहने की जरूरत है क्योंकि अगर ऐप निष्क्रिय होने पर एक जीएल लाइन चलती है- तो यह दुर्घटनाग्रस्त हो जाएगी।

इसके अलावा एक मौका है कि मैं अभी भी बनावट को पूर्व-प्रतिपादन करके डैश की अनुमति दे सकता हूं। यह कुछ काम करने वाला है और यह मेरी मुख्य प्राथमिकता नहीं है, लेकिन मैं एक ओपनजीएल परत की एक साइड प्रोजेक्ट शुरू कर रहा हूं जो CGContext को मूल रूप से बदल सकता है।

ड्राइंग के लिए ओपनजीएल में जाने के बजाय, आप कोर एनिमेशन को कम करने का भी प्रयास कर सकते हैं। शायद CAShapeLayer वर्ग काम कर सकता है। Apple एक जटिल पथ प्रदान करते समय एकाधिक CAShapeLayer s का उपयोग करने की अनुशंसा करता है, इसलिए आपको लाइन सेगमेंट को कई सेगमेंट में विभाजित करने की आवश्यकता हो सकती है। कोर एनिमेशन का उपयोग करके काम को GPU पर ले जाना चाहिए।

मेरे दिन के काम में वर्षों से हमने एक वाणिज्यिक उत्पाद का उपयोग किया है जैसा कि @AlBirdie द्वारा ऊपर बताया गया है, ओपनजीएल का व्यापक उपयोग करता है, और इस प्रकार एनोटेशन को छोड़कर हर चीज के लिए कोरग्राफिक्स को छोड़ देता है। निश्चित रूप से वे काफी बड़े डेटासेट्स का सामना करने में सक्षम हैं, जो कि काफी स्मूथ रेंडरिंग के साथ हैं और वे इसके लिए GPU का उपयोग करने का दावा करते हैं। हालाँकि उनका दृष्टिकोण बड़े पैमाने पर सिरदर्द के साथ आता है, न कि कम से कम बग जो वे प्रतीत होते हैं, उन्हें ठीक करने के लिए परेशान नहीं किया जा सकता है जैसे कि ओपनिंग में क्रैश होने वाली कॉलें जैसे कि ओएनजीसीएल में दुर्घटना, ऐप पृष्ठभूमि में चली गई है, मुहावरेदार वर्ग संरचनाएं और कस्टमाइज़ेबिलिटी पर पागल प्रतिबंध। मैं जो चाहता हूं वह आज मौजूद नहीं है, लेकिन आईओएस-चार्ट में मैं देखता हूं कि यह वहां पहुंचने का तरीका हो सकता है। वैसे भी, मेरे लिए विश्वसनीयता हर बार प्रदर्शन पर जीत जाती है, लेकिन यह सबसे छोटे अंतर से है, दोनों बड़े पैमाने पर महत्वपूर्ण हैं।

पीएस मेरी राय में धराशायी लाइनें उन दिनों से एक हैंगओवर हैं जब कंप्यूटर के पास रंग या यहां तक ​​​​कि ग्रेस्केल में प्रस्तुत करने का विकल्प नहीं था - उनकी आवश्यकता नहीं है जब तक कि हम शुद्ध काले और सफेद को प्रस्तुत नहीं कर रहे हैं और कुछ ऐसा बना रहे हैं जो पुराने जैसा दिखता है लेटरप्रेस-मुद्रित पाठ्यपुस्तक, निश्चित रूप से? ;) तो सामान्य 10K अंक मामले के लिए अनुकूलित करने की तुलना में उन लोगों के लिए अनुकूलित करना बहुत कम महत्वपूर्ण है।

धराशायी लाइनों के संबंध में बिल्कुल आपके साथ @onlyforart ।
आपकी व्यावसायिक चार्टिंग लाइब्रेरी के बारे में आपके विवरण को देखते हुए, मुझे आश्चर्य है कि क्या हम उसी उत्पाद का उपयोग कर रहे हैं। :) हमने आखिरकार इसे वैसे ही छोड़ दिया। मुझे लागू करने में तीन महीने का बेहतर हिस्सा क्या लगा (यहां तक ​​​​कि गंभीर बग और प्रतिबंधों (जैसे क्रॉसहेयर) को पाने के लिए पर्याप्त लंबा नहीं था), आईओएस चार्ट्स ('मूर्खतापूर्ण वर्ग संरचनाएं';)) के साथ केवल दो सप्ताह लग गए। समय और धन की कुल बर्बादी।

@AlBirdie हाँ वह वही है। क्रॉसहेयर का जिक्र भी मत करो। बहुत अधिक न्यूकैसल ब्राउन एले की मदद से बनाया गया था और निस्संदेह कॉर्पोरेट बाजार के उद्देश्य से बनाया गया था (जहां एक शानदार एपीआई वास्तव में एक सकारात्मक बिक्री कारक है, क्योंकि यह ग्राहकों को एक महंगे समर्थन/रखरखाव चक्र में बंद कर देता है)। क्या आप उन लोगों का इतिहास जानते हैं? वास्तव में (अपने गहरे अतीत में) वे सॉफ्टवेयर उद्योग में वास्तविक अग्रणी थे। वैसे भी यह आगे बढ़ने और भविष्य की ओर देखने का समय है।
हम ज्यादातर कैंडलस्टिक चार्ट बनाते हैं (ये वित्तीय क्षेत्र के ऐप हैं)। जो मैं वास्तव में आईओएस और एंड्रॉइड के लिए चाहता हूं वह कुछ ऐसा है जो एचटीएमएल 5/जावास्क्रिप्ट दुनिया में हाईचर्ट्स/हाईस्टॉक के साथ वास्तव में बहुत आसान है:

1. बड़ी संख्या में डेटा पॉइंट (10K या अधिक)
2. ओएचएलसी डेटा का समझदार स्केल बार में स्वचालित समेकन (उदाहरण के लिए ज़ूम कारक उपयुक्त होने पर 1 एच बार दिखाएं, या ज़ूम आउट होने पर 1 मीटर या 1 एस बार दिखाएं)
3. चिकनी पैनिंग और स्क्रॉलिंग
4. आकर बड़ा करो
5. एकाधिक डेटा श्रृंखला और एनोटेशन और क्रॉसहेयर को ओवरले करना, कुछ प्रोग्रामिक रूप से और कुछ उपयोगकर्ता इंटरैक्शन द्वारा उदाहरण के लिए एक सीमा मूल्य निर्धारित करने के लिए, सभी को सुचारू रूप से प्रस्तुत किया गया
6. (यहां किकर है - हाईस्टॉक इससे मदद नहीं करता है! हालांकि यह मेरे लिए बहुत स्पष्ट लगता है) डेटा की वृद्धिशील फ़ेचिंग (लुकहेड के साथ) उदाहरण के लिए पूरे डेटासेट के लिए कम रिज़ॉल्यूशन डेटा प्राप्त करना और, मैप ऐप्स के साथ, हाई-रेज प्राप्त करना डेटा (उदाहरण के लिए मिलीसेकंड "टिक" डेटा) केवल चार्ट के देखे गए क्षेत्र के लिए
   हम अभी तक आईओएस-चार्ट का उपयोग नहीं कर रहे हैं, हालांकि यह मेरी "टू-डू" सूची में है और शीर्ष के करीब पहुंच रहा है, इसलिए मैंने अभी तक कोड के अंदर नहीं देखा, लेकिन जैसे ही मैं करता हूं - शायद अगले महीने - मैं वह सब देख लूंगा।
   रेंडरिंग पर वापस, ओपनजीएल के क्रैश होने की प्रवृत्ति अगर परिस्थितियां सही से कम हैं तो चिंता का विषय है। GLKit GPU ड्राइंग में मदद कर सकता है; मैंने कुछ समय पहले भी सोचा था कि क्या स्प्राइटकिट मदद कर सकता है (चार्ट प्रतिपादन गेम बनाने से दस लाख मील नहीं है), लेकिन अभी जीएलकिट एक बेहतर उम्मीदवार लगता है।

LOL @onlyforart , आपने मुझे न्यूकैसल ब्राउन एले में दिया था। :+1: :)
मैं आपकी आवश्यकताओं के बारे में एक ही नाव में हूं (वित्त उत्पादों पर भी काम कर रहा हूं), लेकिन हां, आइए इन चार्टों की वास्तविक ड्राइंग पर वापस जाएं। भविष्य में आपके निष्कर्षों की प्रतीक्षा है।

@onlyforart, अपनी अंतर्दृष्टि के लिए @AlBirdie धन्यवाद :-)

लोगों को हमारे पुस्तकालय के लिए व्यावसायिक उद्यम उत्पाद को छोड़ते हुए देखना वाकई अच्छा है, हालांकि मुझे उनके लिए बुरा लगता है... मैं विवादित हूं!

मैं ओपनजीएल को इसका एक टुकड़ा देने में संकोच कर रहा था क्योंकि मुझे पता था कि अगर यह पूरी तरह से प्रबंधित नहीं है तो संभावित क्रैश हो सकते हैं, और यह वास्तव में UIKit ऐप में संभव नहीं है। यदि आप गेम बनाने के लिए ओपनजीएल का उपयोग कर रहे हैं, तो पूरी चीज ओपनजीएल कैनवास है और आपको यूआईकिट कॉल के बारे में चिंता करने की ज़रूरत नहीं है, जबकि पृष्ठभूमि में ओपनजीएल प्रतिपादन करने की कोशिश कर रहा है।

@onlyforart धराशायी लाइनों के बारे में आपकी बात सही है, लेकिन दुर्भाग्य से मुझे ग्राहकों के साथ धराशायी लाइनों की मांग करने का अनुभव हुआ है। एंड्रॉइड पर एक मामला था जहां प्रदर्शन को बढ़ावा देने के लिए डेवलपर को परत को हार्डवेयर परत में बदलना पड़ा, और क्लाइंट को बताया कि धराशायी लाइनें ठोस रेखाएं बन जाएंगी, यही लागत है। और निश्चित रूप से सभी ड्राइंग कोड को ओपनजीएल में स्थानांतरित करने का एक विकल्प है, लेकिन फिर एक रेखा खींचना सिरदर्द है, लेकिन आप एक धराशायी रेखा के लिए बनावट बना सकते हैं और इसके साथ काम कर सकते हैं। वे इसके लिए भुगतान नहीं करना चाहते थे इसलिए धराशायी लाइनें निश्चित रूप से इतनी महत्वपूर्ण नहीं थीं, लेकिन उन्होंने इसके बारे में बहुत शोर मचाया।

मेरे लिए एक नोट: प्रतिपादन के लिए GLKit का उपयोग करने का प्रयास करें। देखते हैं क्या होता है।

और अगर मैं आपकी सूची लेता हूं:

1. _"बड़ी संख्या में डेटा पॉइंट (10K या अधिक)"_ - हम इस पर काम कर रहे हैं :) मैं Android के बारे में नहीं कह सकता, क्योंकि इसे GL में ले जाना और भी बड़ा PITA होगा, लेकिन यह पहले से ही बहुत अच्छा प्रदर्शन कर रहा है हार्डवेयर परत का लाभ उठाना, जो GPU पर सभी आरेखण कर रहा है।
2. _"ओएचएलसी डेटा का समझदार स्केल बार में स्वचालित समेकन"_ - हम बहुत जल्द सन्निकटन फ़िल्टर का उपयोग करने जा रहे हैं, इसलिए मुझे लगता है कि यह इसका ध्यान रखेगा। कई 1m बार होने के बजाय जिन्हें आप नहीं पढ़ सकते हैं, आपके पास 1 घंटे का बार आदि का अनुमान होगा।
3. _"चिकनी पैनिंग और स्क्रॉलिंग"_ - किया :-)
4. _"पिंच टू जूम"_ - किया :-)
5. _"एकाधिक डेटा श्रृंखला और एनोटेशन और क्रॉसहेयर को ओवरले करना"_ - मुझे नहीं पता कि क्या मैं सही ढंग से समझता हूं, लेकिन वर्तमान में एक संयुक्त चार्ट है जो कई चार्ट प्रकारों को ओवरले कर सकता है, और प्रत्येक चार्ट प्रकार कई डेटासेट स्वीकार कर सकता है। इसके अलावा, आप हमेशा ViewPortHandler में हुक कर सकते हैं और निर्देशांक ले सकते हैं ताकि आप चार के शीर्ष पर जो चाहें ओवरले कर सकें
6. डेटा की वृद्धिशील प्राप्ति - हम डेटा स्रोत को सारगर्भित करने की योजना बना रहे हैं, जबकि स्थिर डेटासेट सेट करने के लिए अभी भी पुराने एपीआई हैं (यह केवल डेटा स्रोत में बनाया जाएगा जो उनके साथ काम करता है)। मुझे लगता है कि यह आपकी आवश्यकता के अनुरूप भी होगा, लेकिन हम नहीं जानते कि हम इसे कब प्राप्त करेंगे

@danielgindi , उनके लिए बुरा मत

दूसरी आवश्यकता के संबंध में, यदि आप लोग इसे लागू करने जा रहे हैं, तो यह वैकल्पिक होना चाहिए। हमें अपने चार्टिंग उत्पादों में से एक में इस तरह का समेकन मिला है और ग्राहक इसके बजाय लगातार एक निश्चित आवृत्ति की ओर बढ़ रहे हैं। ज़ूमिंग के दौरान आवृत्तियों को बदलना न केवल औसत वित्त चार्ट उपयोगकर्ता के लिए भ्रमित करने वाला साबित हुआ, बिजली उपयोगकर्ता नाराज हो गए क्योंकि वे निश्चित आवृत्तियों को चाहते थे।

हमने उपयोगकर्ताओं पर इसे थोपने की कभी कल्पना भी नहीं की थी! आप देख सकते हैं कि कोड में पहले से ही फ़िल्टर शामिल हैं, और MPAndroidCharts में आप ऐतिहासिक रूप से देख सकते हैं कि फ़िल्टर एक ऐसी संपत्ति द्वारा सक्षम किए गए थे जो फ़िल्टर (कोई भी कस्टम फ़िल्टर या बिल्ट इन) सेट करता है, लेकिन बाद में संरचनात्मक परिवर्तनों के कारण हटा दिया जाता है।

जब हम इसे लागू करते हैं तो कार्यक्षमता वही रहेगी - यह सिर्फ एक और अच्छी सुविधा होगी :-)

@AlBirdie Re "दूसरी आवश्यकता के संबंध में, यदि आप लोग इसे लागू करने जा रहे हैं, तो यह वैकल्पिक होना चाहिए। हमने अपने चार्टिंग उत्पादों में से एक में इस तरह का समेकन प्राप्त किया है और ग्राहक लगातार एक निश्चित आवृत्ति की ओर बढ़ रहे हैं। बदल रहा है ज़ूमिंग के दौरान फ़्रीक्वेंसी न केवल औसत वित्त चार्ट उपयोगकर्ता के लिए भ्रमित करने वाली साबित हुई, बिजली उपयोगकर्ता नाराज हो गए क्योंकि वे निश्चित आवृत्तियों को चाहते थे।" पूरी तरह से सहमत - यह सूचनात्मक/गैर-व्यापारिक उपयोगकर्ताओं के लिए चार्ट के लिए है। ट्रेडिंग उपयोगकर्ताओं की अलग-अलग ज़रूरतें होती हैं।

@danielgindi Re "डेटासोर्स को

क्या किसी ने ड्रॉइंग कोड को अलग-अलग थ्रेड्स (CALayer.drawsAतुल्यकालिक रूप से) में विभाजित करने के साथ खेला? यह उस स्थिति में मदद कर सकता है जब यह चार्ट अतिरिक्त, प्रत्येक डेटासेट, ग्रिड और कुल्हाड़ियों को अलग से खींचने की अनुमति देता है। कोरग्राफिक्स के साथ मेरे बहुत ही विनम्र अनुभव को देखते हुए (पढ़ें; कोई भी नहीं ;-)), मैंने इसके साथ कोई प्रयोग नहीं किया है, मैंने इसे तब पाया जब मैं जीएलकिट की तलाश में था और यह चार्ट प्रदर्शन को कैसे सुधार सकता है।

मुझे 10k डेटा बिंदुओं के साथ एक कैंडल स्टिक चार्ट दिखाने की आवश्यकता थी इसलिए मैंने CandleStickChartRenderer.drawDataSet() पर कुछ समय मापन चलाया।

यह पता चला कि ज्यादातर समय dataSet.entryIndex (लाइन 76,77) पर कॉल करने में व्यतीत होता है।

मुझसे गलती हो सकती है, लेकिन ऐसा लगता है कि dataSet.entryIndex() कॉल _minX के रूप में बेमानी है, _maxX मान हमेशा minx के बराबर होते हैं, maxx dataSet.entryIndex() से लौटाया जाता है।

मैंने 10k डेटा पॉइंट्स के साथ एक कैंडल स्टिक चार्ट बनाने में कामयाबी हासिल की है / आसानी से ज़ूम किया है। बदल के
CandleStickChartRenderer.swift, लाइन 76,77 से:

var minx = अधिकतम (dataSet.entryIndex (प्रविष्टि: entryFrom, isEqual: true), 0);
var maxx = min(dataSet.entryIndex(entry: entryTo, isEqual: true) + 1, entry.count);

सेवा मेरे

वर मिनक्स = अधिकतम (_minX, 0);
वर मैक्सएक्स = _मैक्सएक्स + 1;

मैंने LineChartRenderer में वही परिवर्तन किया है और 2 डेटा श्रृंखला (प्रत्येक 10k डेटा अंक) के साथ एक संयुक्त कैंडल स्टिक/लाइन चार्ट दिखाने में सक्षम था।

वाह, यह एक विशाल प्रदर्शन वृद्धि है @dorsoft !

मैंने अभी इसका परीक्षण किया है और मुझे अपनी आंखों पर विश्वास नहीं हो रहा है। यहां तक ​​​​कि एक आईपैड 2 पर 4 संयुक्त चार्ट के साथ प्रत्येक में 250 डेटापॉइंट्स के साथ प्रत्येक में तीन डेटासेट दिखाए जा रहे हैं और वाई अक्ष की स्वचालित न्यूनतम/अधिकतम गणना अब हम सभी चार्टों को एक साथ काफी सहज तरीके से पैन और ज़ूम करने में सक्षम हैं। यह 60fps नहीं है, लेकिन करीब है। इस तरह के एक पुराने डिवाइस और WAY (!) के लिए प्रभावशाली, पहले की बात की गई व्यावसायिक OpenGL समाधान से अधिक तेज़ है।

मुझे लगता है कि मुझे यह कोशिश करनी है :) और फिल के साथ भी चर्चा करने की आवश्यकता है
समझें कि क्या कोई प्रभाव है ...

मैं सिर्फ यह पढ़ता हूं, बहुत दिलचस्प लगता है लेकिन यह देखने के लिए कुछ गहन परीक्षण की आवश्यकता है कि क्या यह वास्तव में सभी परिदृश्यों के लिए उपयुक्त है :-)

मैंने कैंडल चार्ट के प्रदर्शन में वृद्धि के साथ एक पीआर बनाया है।
ऑटो स्केल न्यूनतम/अधिकतम और शून्य मानों का उपयोग करके संवर्द्धन का अच्छी तरह से परीक्षण किया गया था।

मुझे एक संभावित अड़चन मिली है। एक रीयलटाइम चार्ट में चार्ट में प्रति सेकंड कई प्रविष्टियां जोड़ते हुए मैंने देखा कि स्वचालित रूप से डेटासेट के कैल्कमिनमैक्स को प्रत्येक values.append(e) ठीक बाद कहा जाता है

CalMinMax फ़ंक्शन .forEach का उपयोग करके न्यूनतम और अधिकतम मान निर्धारित करता है, जो मुख्य थ्रेड में इसके अलावा, मूल्यों को लूप करने में 60% से अधिक CPU का कारण बन रहा है।

मैं कुछ प्रयोग कर रहा हूं जो न्यूनतम/अधिकतम गणना को अक्षम कर रहा है या सरणी के बजाय मूल के लिए लूप का उपयोग कर रहा है। forEach

@danielgindi कृपया एक नज़र डालें, क्या वास्तव में सभी मूल्यों पर कैल्कमिनमैक्स आवश्यक है? मैं अपने कोड में और केवल दृश्यमान मानों पर मैन्युअल रूप से न्यूनतम/अधिकतम वाई मानों की गणना करता हूं, इसलिए हो सकता है कि आप न्यूनतम/अधिकतम ऑटो गणना को सक्षम/अक्षम करने के लिए कुछ बूलियन का पर्दाफाश कर सकें और प्रत्येक फ़ंक्शन को हटाने और फ़ंक्शन कॉल से बचने के प्रदर्शन में सुधार कर सकें।

```
open override func calcMinMax()
{
    guard !values.isEmpty else { return }

    _yMax = -Double.greatestFiniteMagnitude
    _yMin = Double.greatestFiniteMagnitude
    _xMax = -Double.greatestFiniteMagnitude
    _xMin = Double.greatestFiniteMagnitude

    values.forEach { calcMinMax(entry: $0) }
}

```

@samueleperricone कृपया इसे एक अलग टिकट

@jjatie धन्यवाद, # 3166 खुला

मैं iOS के लिए लाइन चार्ट में 13000 से अधिक रिकॉर्ड लोड कर रहा हूं। लेकिन, चार्ट लोड करते समय UI को फ्रीज कर देता है। साथ ही, लोड करने के बाद यदि उपयोगकर्ता किसी बिंदु का चयन करता है तो चयन को हाइलाइट करने में भी बहुत अधिक समय लगता है।