टेलीग्राम के सक्रिय उपयोगकर्ता, विशेषकर जो पावेल ड्यूरोव के सदस्य हैं, उन्होंने शायद इस तथ्य के बारे में कुछ सुना है कि टेलीग्राम ने iOS, एंड्रॉइड और जावास्क्रिप्ट डेवलपर्स के साथ-साथ डिजाइनरों के लिए, आपके इन इंटरनेट साइटों पर एक प्रतियोगिता आयोजित की है। इस तथ्य के बावजूद कि यह ठोस पुरस्कारों के वितरण के साथ बल्कि एक महाकाव्य घटना थी (प्रतिभागियों में से एक को पहले स्थान के लिए $ 50k प्राप्त हुआ, सबसे तेज़ और सबसे आसान एंड्रॉइड एप्लिकेशन लिखा गया), उन्होंने किसी तरह इसके बारे में बहुत कम लिखा, कम से कम रनेट पर। मेरी पहली पोस्ट स्थिति को ठीक करने की कोशिश करेगी।


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


विभिन्न प्लेटफार्मों के लिए डेवलपर्स एक दूसरे के साथ प्रतिस्पर्धा नहीं करते थे, और प्रत्येक मंच के अपने स्वयं के विजेता थे। मुख्य मानदंड थे: काम की गति (पुराने उपकरणों सहित), डिजाइन के साथ स्थिरता, चिकनी एनीमेशन और न्यूनतम आवेदन आकार। पहले से मौजूद समाधान और पुस्तकालयों का उपयोग नहीं किया जा सकता था, सब कुछ खरोंच से लिखा जाना था।

इससे पहले, मैंने डेवलपर्स के लिए प्रतियोगिताओं में भाग लिया था, जहां सभी कार्यों के लिए 5 घंटे से अधिक समय आवंटित नहीं किया गया था, इन घंटों को जबरदस्त तनाव में बिताना पड़ा। इस तथ्य के बावजूद कि टेलीग्राम को कार्य पूरा करने के लिए इस तरह के तनाव की आवश्यकता नहीं थी, यह सबसे कठिन प्रतियोगिताओं में से एक है जिसमें मुझे भाग लेना था। ऐसा प्रतीत होता है कि बिना सोचे-समझे कार्य इतनी क्षमता से बदल गया कि अगर मुझे इसके लिए भुगतान किया गया, तो मैं महीनों तक इन "रेखांकन" को काट सकता था, कोड प्रदर्शन और इसके वास्तु सामंजस्य के बीच समझौता करने की कोशिश कर रहा था। इसने मदद की कि तीन ( अपडेट : दो, संशोधन के लिए vlad2711 के लिए धन्यवाद) सप्ताह समाधान के लिए आवंटित किए गए थे। कुछ प्रतिद्वंद्वियों ने विशेष रूप से प्रतियोगिता के लिए अधिक समय समर्पित करने के लिए छुट्टी ली, और मैंने शाम को प्रतियोगिता में विकास के लिए और " ओंटेंटा " में हमेशा की तरह काम के साथ संयोजन करने का फैसला किया।

CANVAS बनाम एसवीजी

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

कैनवास

+ पूर्ण बहुमुखी प्रतिभा - कैनवास पर किसी भी पिक्सेल के रंग को बदलने की क्षमता रखते हुए, आप अपनी इच्छानुसार कुछ भी आकर्षित कर सकते हैं।
+ [संभावित] उच्च प्रदर्शन - यदि आप कैनवास तैयार कर सकते हैं, तो यह अच्छा प्रदर्शन दिखा सकता है। वेबलॉग का उपयोग करना बहुत अच्छा होगा, लेकिन स्मार्टफ़ोन पर इसका समर्थन खराब है।

- सभी गणना और हाथ से सभी प्रतिपादन - एसवीजी के विपरीत, जहां पॉलीलाइन के मध्यवर्ती बिंदुओं को एक बार सेट किया जा सकता है, और फिर आप पॉलीलाइन के अनुभागों के साथ "कैमरा" को स्थानांतरित करने के लिए व्यूबॉक्स को हेरफेर कर सकते हैं, कैनवास के साथ सब कुछ अधिक जटिल है, यहां "कैमरे" नहीं हैं। केवल ऊपरी बाएं कोने से निर्देशांक; यदि आपको चार्ट के वर्तमान दृश्य क्षेत्र को "स्थानांतरित" करने की आवश्यकता है, तो आपको देखने के क्षेत्र की नई स्थिति के सापेक्ष उसके सभी बिंदुओं के सभी निर्देशांकों की पुन: गणना करनी होगी। दूसरे शब्दों में, व्यूबॉक्स, जो कि svg बॉक्स से बाहर है, को कैनवास में मैन्युअल रूप से लागू करने की आवश्यकता है।
- पूरा एनीमेशन मैनुअल है - पिछले पैराग्राफ के आधार पर, निर्देशांक, रंग और पारदर्शिता मानों को पुन: प्राप्त करके और प्रति सेकंड पूरे दृश्य एन-वें नंबर को कई बार पुन: संयोजित करके और अधिक बार दृश्य को पुनरावृत्त करना और संभव हो जाता है, दृश्य को सुचारू करने के द्वारा सभी संभव एनिमेशन का एहसास होता है।

एसवीजी

+ सरल आरेखण - बस व्यूपोर्ट, रंग और पारदर्शिता मापदंडों में हेरफेर करके एसवीजी को एक बार आवश्यक लाइनें, आकार और अधिक जोड़ दें, ग्राफ़ नेविगेशन प्रदान करें।
+ एनिमेशन का सरल कार्यान्वयन - फिर से, पिछले पैराग्राफ के आधार पर, व्यूबॉक्स, रंग और पारदर्शिता प्रति सेकंड की संख्या के लिए नए मान निर्दिष्ट करने के लिए पर्याप्त Ne है, और छवि को फिर से परिभाषित किया जाएगा, ब्राउज़र इस बात का ध्यान रखेगा। इसके अलावा, यह मत भूलो कि एसवीजी में आकृतियों और प्राइमेटिव्स को सीएसएस में स्टाइल किया जा सकता है, इसलिए उन्हें CSS3 एनिमेशन का उपयोग करके एनिमेटेड किया जा सकता है, जो न्यूनतम प्रयास के साथ शांत एनिमेशन प्राप्त करने की व्यापक संभावनाएं खोलता है।
+ डिफ़ॉल्ट रूप से अच्छा प्रदर्शन - यदि आप आसानी से कुछ धीमी गति से और कैनवास पर सैकड़ों संसाधनों का उपभोग कर सकते हैं, तो एसवीजी पर आधारित परिणाम हमेशा काफी हल्का, सभ्य और चिकना दिखेगा।

लेकिन सिक्के का एक दूसरा पहलू भी है।

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

मुझे कभी भी टूल चुनने के बारे में चिंता करने की आवश्यकता नहीं थी, क्योंकि मेरे पास एक घृणित चरित्र विशेषता है - मैं एक मैक्सिममिस्ट हूं और अपने काम में केवल अपने पसंदीदा टूल का उपयोग करता हूं। ऐसा हुआ कि मेरे छात्र दिनों के बाद से, जब मैं डायरेक्टड्रा के साथ खुद को खुश कर रहा था, मेरा पसंदीदा उपकरण हमेशा एक कैनवास था जिस पर "आप जो चाहते हैं वह करते हैं।" और एक प्रतिस्पर्धी समस्या को हल करने के लिए कैनवस वास्तव में अच्छा निकला, लेकिन यह वास्तव में मेरे हाथों में खेला गया था इसके प्लसस में से केवल एक: अनुकूलन के लिए व्यापक संभावनाएं, क्योंकि मुख्य मानदंड अभी भी आवेदन प्रदर्शन था।

अच्छा कोड अच्छा नहीं है

कार्य स्पष्ट है: आपको कैनवास पर सही जगह और सही समय पर अंक खींचने की आवश्यकता है। यह कोड लिखने के लिए रहता है। फिर, यह चुनना आवश्यक था, इस बार प्रक्रियात्मक शैली में एक "फुटक्लॉथ" के साथ एक उत्पादक कॉम्पैक्ट कोड लिखने के बीच या मेरे पसंदीदा ऑब्जेक्ट-ओरिएंटेड में बहुत अधिक उत्पादक और यहां तक ​​कि गैर-कॉम्पैक्ट भी नहीं। आपने शायद पहले ही अनुमान लगा लिया था कि मैंने अपने पसंदीदा - टाइपस्क्रिप्ट के एक और विकल्प के साथ इसे चुना, दूसरा विकल्प चुना।

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

यह जीथब के लिए एक लिंक देने का समय है: github.com/native-elements/telechart । यदि दिलचस्पी है, तो मैं कमिट्स के इतिहास पर ध्यान देने की सलाह देता हूं; यह ऑप्टिमाइज़िंग ऑर्डिलेस की स्मृति रखता है और प्रति सेकंड अतिरिक्त रेंडर फ्रेम के एक जोड़े को निचोड़ने के असफल प्रयास करता है।

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

मेरे पेशेवर जीवन के सबसे मूल्यवान पाठों में से एक जो मैं पाने के लिए नहीं थकता हूं, वह यह है कि एक अच्छा इंजीनियर, उदाहरण के लिए, एक कलाकार, अपने काम की गुणवत्ता का मूल्यांकन करने के लिए बाध्य होता है, आत्मविश्वास को त्याग देता है, क्योंकि उसके काम का परिणाम केवल आंख पर नहीं होना चाहिए लेकिन सही ढंग से और अच्छी तरह से काम करना चाहिए।

यह प्रतियोगिता का पहला चरण था। विजेताओं को उदारता से पुरस्कृत किया गया। मेरे अवर्णनीय आनंद के लिए, कहानी वहाँ समाप्त नहीं हुई, क्योंकि दूसरे चरण की घोषणा की गई थी:


अतिरिक्त प्रकार के चार्ट को लागू करने के एक सप्ताह में, अपने शिल्प को परिष्कृत करना आवश्यक था। जो हुआ, उसे मैं तुरंत दिखाऊंगा और नीचे मैं आपको बताऊंगा कि यह कैसे हुआ।


मेरे मामले में, नई कार्यक्षमता जोड़ने से पहले, मुझे पुराने के प्रदर्शन को समझना होगा। पहली समस्या जो मैंने हल की है

चिकोटी एनीमेशन

यहां तक ​​कि अगर आपके पास 60 फ्रेम प्रति सेकंड का उत्पादन करने की पर्याप्त शक्ति है, तो एनीमेशन चिकनी नहीं होगा यदि तत्व की स्थिति या इसकी पारदर्शिता एनीमेशन की शुरुआत के बाद से बीत चुके समय से निर्धारित नहीं होती है। यह टिक्स के बीच असमान समय अंतराल के कारण है: उदाहरण के लिए, एक टिक ने 10 एमएस के बाद काम किया, और 40 के बाद दूसरा, जबकि पहली और दूसरी टिक के लिए ऑब्जेक्ट को 1 पिक्सेल द्वारा बाईं ओर ले जाया गया - अर्थात, इसकी गति की गति लगातार तैरती रहती है। नेत्रहीन यह एक "चिकोटी" जैसा दिखता है। दूसरे शब्दों में, आपको कुछ गलत करने की आवश्यकता है:

let left = 10, interval = setInterval(() => { left += 1 if (left >= 90) { clearInterval(interval) } }, 10) 

और इसलिए:

 let left = 10, startLeft = 10, targetLeft = 90, startTime = Date.now(), duration = 1000, interval = setInterval(() => { left = startLeft + (targetLeft - startLeft) * (Date.now() - startTime) / duration if (left >= targetLeft) { left = targetLeft clearInterval(interval) } }) 

चूंकि कोड में बहुत सारे एनिमेटेड पैरामीटर हैं, इसलिए मैंने एक सार्वभौमिक वर्ग को फिल्माया है जो कार्य को आसान बनाता है, और एनीमेशन में इज़िंग भी जोड़ता है। इसका उपयोग करना काफी आसान है:

 let left = Telemation.create(10, 90, 1000) … drawVerticalLine(left.value) //      ,  . 

तब 60 एफपीएस नियम लागू होता है। पीसी गेमर्स मुझे समझेंगे: एक एनीमेशन को सही दिखने के लिए, इसे कम से कम 60 एफपीएस की गति से प्रदान किया जाना चाहिए। तदनुसार, फ्रेम के प्रत्येक प्रतिपादन को 1/60 सेकंड से अधिक नहीं लेना चाहिए। इसके लिए शक्तिशाली हार्डवेयर और अच्छे कोड की आवश्यकता होती है।

आगे के शोध से पता चला है कि

यदि कैनवास के ऊपर html तत्व हैं, तो पेंटिंग कैनवास धीमा हो जाता है ।

प्रारंभ में, मैंने वर्तमान व्यूपोर्ट पर नियंत्रण लागू करने के लिए "खाली" html तत्वों का उपयोग किया:


इन तत्वों को कैनवास के शीर्ष पर रखा गया था, और इस तथ्य के बावजूद कि उनके पास कोई सामग्री नहीं थी, उनका उपयोग केवल माउस घटनाओं को ट्रैक करने के लिए किया गया था, प्रयोगों के परिणामस्वरूप यह पता चला कि उनकी बहुत उपस्थिति प्रतिपादन प्रदर्शन को कम करती है। उन्हें हटाने और देखने के क्षेत्र को थोड़ा नियंत्रित करने के लिए घटनाओं को निर्धारित करने के तर्क को जटिल करके, मैंने फ्रेम को प्रदान करने की गति बढ़ा दी।

यह प्रदर्शन के ताबूत के ढक्कन से आखिरी कील खींचने के लिए बना रहा: मैंने किया

मिनिमप कैशिंग

इससे पहले, न्यूनतम फ्रेम के लिए हर फ्रेम को फिर से खींचा गया था। यह एक महंगा ऑपरेशन है क्योंकि इसने पूरे वर्ष (365 अंक प्रति पंक्ति) के लिए पूरे कार्यक्रम को प्रदर्शित किया। स्पष्ट समाधान, जिसे मैं बहुत शुरुआत से लागू करने के लिए बहुत आलसी था, न्यूनतम चार्ट के लिए एक बार चार्ट की रेखाएं खींचना था, परिणाम को कैश में सहेजें और भविष्य में इस कैश का उपयोग करें। इस अनुकूलन के बाद, अनुप्रयोग प्रदर्शन अब शर्मनाक नहीं है।

आगे क्या?

प्रदर्शन के लिए अभी भी कई सफल और बहुत अधिक झगड़े नहीं हुए थे: समन्वय गणनाओं के परिणामों को कैश करने का प्रयास, CanvasRenderingContext2D लाइनजोन मापदंडों (तेज मैटर) के साथ प्रयोग, लेकिन वे इतने दिलचस्प नहीं हैं, क्योंकि उन्होंने ध्यान देने योग्य प्रदर्शन लाभ नहीं दिया या बिल्कुल भी नहीं दिया।

आठ दिनों में, मैंने कोड को गति देने में पांच खर्च किए और नई कार्यक्षमता को पूरा करने पर केवल तीन। हां, नए प्रकार के चार्ट को जोड़ने में मुझे केवल तीन दिन लगे, और यहां OOP बहुत उपयोगी साबित हुआ, इसके साथ कोड आधार थोड़ा छोटा था। मेरे पास बोनस कार्य (+5 अतिरिक्त चार्ट) को पूरा करने के लिए पर्याप्त समय नहीं था। मेरा मानना ​​है कि उन पांच दिनों में जो मैंने अपने आत्मविश्वास के परिणामों को खत्म करने पर खर्च किए, मैं बोनस समस्या को हल करने पर खर्च कर सकता था।

फिर भी, मेरे काम का परिणाम निकला: 4 वां स्थान और एक हजार डॉलर का "सांत्वना" पुरस्कार:


वैसे, प्रतियोगिता जारी रही, लेकिन मेरे बिना।

मैं भागीदारी से प्रसन्न हूं: सिर्फ दिलचस्प और एक दिलचस्प साहसिक होने के अलावा, मुझे एक अच्छा पेशेवर अनुभव और जीवन का सबक मिला।

इसके अलावा, मैंने अपने कॉर्पोरेट टाइमक्रैकर के विकास में इस लाइब्रेरी का उपयोग किया, जिसके बारे में मैं निकट भविष्य में बात करना चाहता हूं।

चर्चा के लिए, मैं निम्नलिखित प्रश्न का प्रस्ताव करता हूं: टेलीग्राम को यह सब क्यों चाहिए? मेरा मानना ​​है कि पर्याप्त धन के लिए, टेलीग्राम को चार्ट प्रदर्शित करने के लिए दुनिया में सर्वश्रेष्ठ पुस्तकालय प्राप्त होगा: दूसरों की तुलना में बेहतर करने के सैकड़ों प्रयासों का सबसे अच्छा परिणाम। प्रतिस्पर्धी सिद्धांत आपको उच्च स्तर की गुणवत्ता प्राप्त करने की अनुमति देता है जो कोई भी ऑर्डर पर और बिना पैसे के नहीं कर सकता है।

और कुछ लिंक:

• प्रतियोगिता के परिणाम: t.me/contest/81
• सभी प्रतिभागी प्रतिभागी: प्रतियोगिता.देव / अचत्- जज
• प्रतियोगिता वेबसाइट पर मेरा पेज: प्रतियोगिता.देव / एक्ट- जेएस / पेंट्री website४
• मेरा आवेदन: jschart.usercontent.dev/entry74
• यदि कोई टेलीग्राम नहीं है, तो आप यहां देख सकते हैं: asyncoders.com/telechart/index.html