Three.js: कुछ ES6 सुविधाओं को अपनाएं

शायद थोड़ा जल्दी? समर्थन लगातार महान क्रॉस ब्राउज़र नहीं है: http://kangax.github.io/compat-table/es6/

let एफएफ में उजागर नहीं हुआ और क्रोम और आईई में 100% स्थितियों में नहीं।
generators IE में उपलब्ध नहीं है
class केवल क्रोम में है, Win10 और FF39 के लिए IE12 (स्पार्टन) तकनीकी पूर्वावलोकन जो वर्तमान संस्करण से दो ऊपर है।
import अभी तक कहीं भी उपलब्ध नहीं है
super केवल IE12 में उपलब्ध है, IE11, Chrome या FF में नहीं
arrow functions IE11 या क्रोम में नहीं है

साथ ही जेनरेटर और for-of दोनों क्रोम के लिए ऑप्टिमाइज़ेशन किलर हैं

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

मुझे ES6 पार्टी में थोड़ी देर हो गई है। यह मुझे एक अलग भाषा लगती है। मैं नियमित रूप से तीन.जेएस में योगदान देता हूं, लेकिन अगर यह उपरोक्त स्निपेट की तरह दिखता है, तो मुझे नहीं पता कि मैं जारी रखूंगा या नहीं। मेरे पास जावास्क्रिप्ट का एक अलग दिखने वाला और अलग-अलग-कार्यशील संस्करण सीखने का धैर्य नहीं है, जो मूल रूप से 'नया फ़ंक्शन ()' और 'ऑब्जेक्ट.प्रोटोटाइप' जैसा ही काम करता है, लेकिन संभवतः धीमा।

क्या वेब समुदाय ES6 भाषा समिति से यही मांग कर रहा है? मैं 20 साल से कोडिंग कर रहा हूं और 'क्लास' शब्द मेरी परियोजनाओं में कहीं भी नहीं दिखाई देता है (न ही अगर मेरे पास मेरा रास्ता है तो यह कभी भी नहीं होगा)। सच कहूं तो, जावास्क्रिप्ट जावा...(स्क्रिप्ट) की तरह दिखने लगा है। :-\

मैं @benaadams और @jonnenauha के साथ

:+1:

@erichlof खैर, मैं वास्तव में ES6 वर्ग और मॉड्यूल का सबसे अधिक समर्थन करने की प्रतीक्षा कर रहा हूं। मैं वर्तमान में अपने ऐप्स के लिए AMD का उपयोग कर रहा हूं। मुख्य जेएस परियोजना जिस पर मैं काम करता हूं वह ~ 10k लाइनें है जिसमें सैकड़ों "कक्षाएं" हैं और एएमडी एक जीवन रक्षक है। दोनों विकास के दौरान और निर्माण के निर्माण में। इमो बड़ी या छोटी परियोजनाओं में किसी प्रकार की मॉड्यूल प्रणाली और चीजों को घोषित करने का एक तरीका होना चाहिए कि वे किस पर निर्भर हैं। एक बार आपके पास एक जटिल परियोजना संरचना होने के बाद इसे प्रबंधित करना बहुत बालों वाला हो जाता है। 25x <script> टैग लगाने के क्रम में यह पता लगाने के लिए प्रोग्राम के लिए इसे नहीं छोड़ा जाना चाहिए। एक बार आपके पास तीन.जेएस जैसी फाइलों की मात्रा होने के बाद यह मूर्खतापूर्ण है। अधिकांश प्रोजेक्ट एक बड़ी जेएस फ़ाइल (जैसे तीन.जेएस) बनाकर इसे हल करते हैं और फिर एक यादृच्छिक अतिरिक्त/सहायक फ़ोल्डर होते हैं जहां आप अन्य सामान शामिल कर सकते हैं। यह कुछ हद तक सीमित है और मुझे सूर्य के नीचे ~ सब कुछ प्राप्त करने के लिए ~ 500kb (मिनीफाइड) बिल्ड शामिल करना होगा।

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

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

मैं केवल इतना कह रहा हूं कि ES6 कक्षाएं और मॉड्यूल तीन.जेएस के लिए भी एक अच्छा अतिरिक्त होगा ताकि इसे कुछ और संरचना और निर्माण के लिए मॉड्यूलरिटी प्रदान की जा सके। यह बहुत जल्दी है क्योंकि afaik कोई ब्राउज़र समर्थन नहीं करता है। मॉड्यूल अभी तक। अन्य लोग कह सकते हैं कि बस उनका उपयोग करना शुरू कर देना चाहिए और बेबेल आदि का उपयोग करना चाहिए और आउटपुट ES5 अनुरूप बनाता है, मुझे यकीन नहीं है कि यह एक अच्छा विचार है, लेकिन कौन जानता है। यह विकास को कठिन बनाता है, जब आप फ़ाइलों को सहेजते हैं तो आपको बिल्ड को स्वतः शुरू करना पड़ता है, और डिबगिंग भी अधिक जटिल हो सकती है। अकेले इन चीजों के लिए मुझे लगता है कि ये ट्रांसपिलर इसके लायक नहीं हैं।

पीएस तीन.जेएस के खिलाफ एक शेख़ी नहीं था, बस यह कह रहा था कि ईएस 6 में थ्री.जेएस जैसी परियोजनाओं के लिए लाभ हो सकता है, एक बार ब्राउज़र समर्थन होने के बाद :) और ज्यादातर इसकी पूरी तरह से नई भाषा बनाने की तुलना में इसकी अधिक वाक्य रचनात्मक चीनी। इसमें बस और सामान होगा।

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

एक अच्छा उम्मीदवार https://github.com/mrdoob/three.js/blob/master/src/lights/SpotLight.js#L12 जैसी चीजें हो सकता है, जहां यह एक कमजोर रेफरी हो सकता है और लक्ष्य होने पर स्वचालित रूप से साफ़ हो जाएगा मौके से हटाकर इकट्ठा किया। लेकिन मुझे लगता है कि आप वैसे भी संग्रह पर निर्भर नहीं हो सकते हैं, लेकिन फिर भी दृश्य से लक्ष्य हटा दिए जाने के बाद इसे खत्म करने की आवश्यकता होगी।

कौन जानता है, मैं कुछ ब्लॉग पोस्ट लिखने के लिए विशेषज्ञों की प्रतीक्षा करूँगा कि इन सभी सुविधाओं से ऐप्स को सामान्य रूप से कैसे लाभ हो सकता है :)

हाय @jonnenauha ,

हां, मैं सहमत हूं कि 'आयात' और 'निर्यात' जैसी नई सुविधाएं उपयोगी होंगी, खासकर जहां मॉड्यूलरिटी का संबंध है। मेरा मानना ​​​​है कि यही दिशा है कि @kumavis कस्टम बिल्ड और कोड-बेस रखरखाव के लिए THREE.js को अधिक मॉड्यूलर और प्रबंधनीय बनाने के साथ जाने की कोशिश कर रहे हैं। मैं सभी मॉड्यूल और वस्तुओं और कार्यों के पुन: उपयोग के लिए हूं, खासकर जब हमारे पास एक बड़ा पुस्तकालय प्रारूप है जैसे कि थ्री.जेएस।

हालाँकि, मुझे नहीं लगता कि हमें कक्षाओं की अतिरिक्त वाक्यात्मक चीनी की आवश्यकता है, सुपर, लेट, फॉर, ऑफ़, एरो फ़ंक्शंस, आदि। जब हम मूल रूप से जावास्क्रिप्ट में वही कार्यक्षमता प्राप्त करते हैं जो दशकों से उपयोग में है और एक है पहले से ही बहुत कर्षण। मैं पुरातन हो सकता हूं लेकिन मैं डगलस क्रॉकफोर्ड के साथ हूं जब वह कहता है कि जावास्क्रिप्ट पहले से ही एक वस्तु-उन्मुख भाषा है (अर्थात् कार्य = वस्तुएं = प्रथम श्रेणी के नागरिक), लेकिन 'क्लासिक' नहीं - इसलिए हमें इससे चिंतित नहीं होना चाहिए जावास्क्रिप्ट में शूहॉर्निंग कक्षाएं। इसे एक अलग दृष्टिकोण के साथ डिजाइन किया गया था - एक दृष्टिकोण जिसे मैं पहली बार (1990 के दशक में C / C ++ प्रोग्रामिंग से आ रहा था) द्वारा चकित कर दिया गया था, लेकिन हर बार जब मैं कोड पर बैठता हूं या कोड आर्किटेक्चर को हल करने का प्रयास करता हूं तो मैं अधिक से अधिक सहमत होता हूं समस्या।

THREE.js में वाक्यात्मक परिवर्तन के बजाय मैं नए SIMD प्रोग्रामिंग इंटरफ़ेस जैसी सुविधाओं की ओर माइग्रेशन देखना पसंद करूंगा। मुझे लगता है कि तीनों के गणित कोड (विशेषकर वेक्टर3 और मैट्रिक्स 4) इससे काफी लाभान्वित हो सकते हैं। यहां एक वीडियो लिंक है (समय कोड में 22:51 देखें):
https://youtu.be/CbMXkbqQBcQ?t=1371
जब यह सुविधा प्रमुख ब्राउज़रों में आती है, तो प्रत्येक तीन.जेएस उपयोगकर्ता को परिणामस्वरूप उनके फ्रैमरेट में एक उल्लेखनीय गति दिखाई देगी।

क्षमा करें अगर मेरी पिछली पोस्ट एक शेख़ी की तरह लग रही थी, तो मुझे बस THREE.js पसंद है कि यह अब कैसा दिखता है - मैं आसानी से इसके किसी भी यादृच्छिक भाग का चयन कर सकता हूं और जान सकता हूं कि क्या हो रहा है, यह कहां से आया है, और इसका क्या उपयोग होता है। :)

@erichlof @jonnenauha मुझे यह इंगित करने के लिए मजबूर होना पड़ता है कि es6 कक्षाएं सिर्फ चीनी हैं और वे आंतरिक रूप से रनटाइम पर सब कुछ लागू करने के लिए प्रोटोटाइप तंत्र का उपयोग कर रहे हैं।

मैं काफी आशावादी हूं कि es6 सुविधाएँ कम्प्यूटेशनल प्रदर्शन को प्रभावित नहीं करेंगी। es6 मॉड्यूल लोड समय को प्रभावित कर सकते हैं जब वे अंततः इंजनों द्वारा कार्यान्वित किए जाते हैं, क्योंकि आप एक बड़ी फ़ाइल के बजाय छोटी फ़ाइलों का एक गुच्छा ला रहे हैं। हालांकि HTTP/2 इसे एक गैर-मुद्दा बना सकता है। किसी भी तरह से, यदि हम es6 मॉड्यूल का उपयोग करते हैं तो हम हमेशा की तरह एक बंडल बनाने के लिए browserify का उपयोग कर सकते हैं।

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

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

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

मैं es6 में रुचि रखने वाले किसी भी व्यक्ति को इसमें कूदने और इस रेपो में योगदान करने में मदद करने के लिए प्रोत्साहित करूंगा: https://github.com/5to6/5to6

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

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

और हमें केवल es6 को ही नहीं देखना चाहिए। उदाहरण के लिए, सॉफ्टवेयर रेंडरर चलाने वाली तकनीक के रूप में ams.js बहुत अच्छा होगा। अधिक जानकारी के लिए, http://stackoverflow.com/questions/18427810/three-and-asmjs/18439786#18439786।

और हमें यह नहीं भूलना चाहिए कि अधिकांश योगदानकर्ता मुख्य रूप से योगदान दे रहे हैं क्योंकि जावास्क्रिप्ट परिचित है और es6 अभी तक अधिकांश के लिए नहीं है।

@ जीरो 3 वे अच्छे बिंदु हैं जिनके बारे में मैंने नहीं सोचा था। अगर हम माइक्रो ऑप्टिमाइजेशन की बात कर रहे हैं तो मैं आपसे 100% सहमत हूं। मैं ब्राउज़र समर्थन के बिना उन सुविधाओं का लाभ नहीं उठाना चाहता।

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

अपडेट करें:
शायद किसी को परवाह नहीं है, लेकिन मैंने अपना मन बदल लिया। मेरा मानना ​​है कि हमें कक्षाओं का उपयोग नहीं करना चाहिए। मुझे अभी भी लगता है कि es6 मॉड्यूल एक अच्छा विचार है।

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

THREE.Object3D.call( this );

तथा

THREE.Scene.prototype = Object.create( THREE.Object3D.prototype );

जैसे ही कक्षाएं स्थिर क्रोम और फ़ायरफ़ॉक्स में समर्थित होती हैं, मुझे कोड अपडेट करने पर विचार करने में कोई दिक्कत नहीं होगी

@mrdoob Classes आज स्थिर Chrome 42 और जून FYI में Firefox 39 शिपिंग में समर्थित हैं

आईओएस पर सफारी आजकल खींच रहा है ...

कक्षाएं अद्भुत हैं और अन्य ES7 विशेषताएं भी हैं। हम उन्हें अपनी एक परियोजना में उपयोग कर रहे हैं, लेकिन हमें एक क्रॉस कंपाइलर (babel.js) पेश करना पड़ा क्योंकि हमें सभी ब्राउज़रों - क्रोम, फ़ायरफ़ॉक्स, आईई और सफारी पर चलने की जरूरत है।

बेबेल.जेएस (बेबेलिफाई) चलाने के लिए एक ब्राउजराइज़ ट्रांसफॉर्म है, इसलिए यह मेरे प्रयासों के साथ अच्छी तरह से काम करेगा।

जिज्ञासावश, क्या इनमें से कुछ पर काम शुरू हो गया है? :)

नहीं, क्योंकि हम अभी भी इनकी गति पर पड़ने वाले प्रभावों को नहीं जानते हैं।

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

मैं @erichlof imo से सहमत हूं कि सबसे उपयोगी कार्यान्वयन SIMD (https://github.com/tc39/ecmascript_simd) होगा, यहां तक ​​​​कि

थ्रीजेएस में सिमड कहां फिट होगा? मुझे लगता है कि थ्रीजेएस पहले से ही सभी महत्वपूर्ण गणनाओं को जीपीयू में लोड कर देता है। जबकि मैं वेक्टर कक्षाओं पर इसका उपयोग करके समझ सकता हूं, वहां बहुत कम गणित है जो वास्तव में थ्रीजेएस में किया जाता है, बल्कि ज्यादातर उन वैक्टरों को जीपीयू में ले जाया जाता है।

मैं अनुभव से बात करता हूं क्योंकि मैंने पहले एसएसई 2/एसएसई 4 एक्सटेंशन लागू किए थे और मैंने पाया कि अधिकांश मामलों में लाभ क्षणभंगुर थे - केवल वास्तविक मामले यह एक लाभ था जब मेरे पास बड़े सरणी थे जिन पर मैं ऐसा करना चाहता था कार्यवाही।

हाय @भूस्टन ,
क्या मैट्रिक्स संचालन के लिए भी यही सच है? जब मैं SIMD के बारे में सोच रहा था, तो मैं सोच रहा था कि 4 X 4 मैट्रिक्स ऑपरेशन से सबसे ज्यादा फायदा होगा। और जैसा कि हम सभी जानते हैं, मैट्रिस का उपयोग जावास्क्रिप्ट/सीपीयू पक्ष पर तीन.जेएस में प्रत्येक एनीमेशन फ्रेम में किया जाता है, ऐप की जटिलता से कोई फर्क नहीं पड़ता।

अगर Babylon.js लोगों को कोई आपत्ति नहीं है, तो यह सब शुरू करने का तरीका यहां दिया गया है:
https://github.com/BabylonJS/Babylon.js/blob/master/src/Math/babylon.math.js#L2030 -L2093

मुझे लगता है कि यदि आपको प्रारूप को परिवर्तित करना है तो एक एकल मैट्रिक्स एकाधिक संभावित रूप से हारने वाला है। यदि आपके मैट्रिस हमेशा एक सिम प्रारूप में हैं, तो यह एक लाभ हो सकता है।

लेकिन फिर भी, मैट्रिक्स गुणा अक्सर इष्टतम नहीं होता है क्योंकि आपको स्तंभों को पंक्तियों से गुणा करना होता है, जिसके लिए एक पुन: क्रमित संचालन की आवश्यकता होती है।

मैंने पाया है कि SIMD ऑप्टिमाइज़ेशन (सजातीय संचालन के साथ बड़े सरणियों को छोड़कर) के अधिकांश प्रयास प्रयास के लायक नहीं हैं, लेकिन मुझे पता लगाने के लिए बेंचमार्क करने वाले अन्य लोगों के साथ ठीक है।

परिणामी कोड डिबग करना और साथ ही बनाए रखना कठिन है।

एक रणनीति जो काम कर सकती है वह यह है कि सभी वैक्टर और मैट्रिसेस अपने मूल प्रतिनिधित्व के रूप में एक SIMD संगत मेमोरी लेआउट का उपयोग करें - जो कि क्वेक 3 ने मुझे इसके गणित पुस्तकालय में विश्वास किया था। लेकिन फिर आपको दक्षता के लिए vec2 और vec3 प्रकारों के लिए 4 फ़्लोट्स का उपयोग करना होगा, लेकिन तब यह समस्याग्रस्त हो जाता है जब आप GPU पर अपलोड करना चाहते हैं क्योंकि अब आपके पास अतिरिक्त फ़्लोट हैं।

मैं देखता हूं कि आपका क्या मतलब है, आपकी अंतर्दृष्टि और विशेषज्ञता के लिए धन्यवाद। कुछ समय पहले SIMD.js प्रस्तुति से प्रभावित होना, और इसे तीन.js में चिपकाना और इसे बनाए रखना दो अलग-अलग चीजें हैं जो मुझे लगता है। यह दिलचस्प होगा जैसा आपने कहा था कि कुछ प्रदर्शन तुलनाएं की गई हैं। हो सकता है कि भौतिकी पुस्तकालय जैसे Cannon.js और Oimo.js , जिनका उपयोग तीन.js के संयोजन में किया जाता है, SIMD से अधिक लाभ प्राप्त करेंगे?

@bhouston आह ठीक है जो कुछ समझ में आता है, हालांकि कुछ बेंचमार्क काफी दिलचस्प होंगे।

@erichlof यदि आप रुचि रखते हैं, तो मैंने एक शाखा शुरू की है, https://github.com/Globegitter/three.js/tree/include-SIMD , जहां मैंने वेक्टर 3 को सिमड से बदलना शुरू किया। यह अभी भी एक भारी WIP है और मेरा समय सीमित है इसलिए हम कितना आगे निकल सकते हैं। साथ ही, हर रात नवीनतम फ़ायरफ़ॉक्स का उपयोग करके आप इस कोड को बिना पॉलीफ़िल के चला सकते हैं (जहां मूल कार्यान्वयन स्पष्ट रूप से पॉलीफ़िल की तुलना में ~ 20 गुना तेज़ है: https://blog.mozilla.org/javascript/2015/03/10/state -ऑफ-सिम-जेएस-प्रदर्शन-इन-फ़ायरफ़ॉक्स/)।

@erichlof @jonnenauha मुझे यह इंगित करने के लिए मजबूर होना पड़ता है कि es6 कक्षाएं सिर्फ चीनी हैं और वे आंतरिक रूप से रनटाइम पर सब कुछ लागू करने के लिए प्रोटोटाइप तंत्र का उपयोग कर रहे हैं।
मैं काफी आशावादी हूं कि es6 सुविधाएँ कम्प्यूटेशनल प्रदर्शन को प्रभावित नहीं करेंगी।

आप यह निष्कर्ष निकालने के लिए थोड़ा तेज़ हो सकते हैं: जेएस ऑब्जेक्ट्स के (काफी जटिल) कार्यान्वयन में प्रत्येक जेएस इंजन में ईएस 6 के लिए वास्तव में अलग-अलग कोड पथ हैं।

es6 मॉड्यूल लोड समय को प्रभावित कर सकते हैं जब वे अंततः इंजनों द्वारा कार्यान्वित किए जाते हैं, क्योंकि आप एक बड़ी फ़ाइल के बजाय छोटी फ़ाइलों का एक गुच्छा ला रहे हैं। हालांकि HTTP/2 इसे एक गैर-मुद्दा बना सकता है।

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

क्लोजर कंपाइलर को समझने के लिए Three.js ES6 को संकलित करने और यह देखने की अनुमति देगा कि कब स्विच करने का समय सही है, साथ ही कई अतिरिक्त लाभ। मुझे लगता है कि अभी इस तरह के प्रयास होने चाहिए...

लेकिन फिर भी, [SIMD] मैट्रिक्स गुणा अक्सर इष्टतम नहीं होता है क्योंकि आपको स्तंभों को पंक्तियों से गुणा करना होता है, जिसके लिए एक पुन: क्रमित करने की आवश्यकता होती है।

इस तरह मैट्रिक्स गुणन को लागू करने के लिए SIMD निर्देश सेट में अक्सर "स्केलर से गुणा करें और जोड़ें" निर्देश होता है:

for i : 0..3:
    dst.col[i] = lhs.col[i] * rhs.co[i][0] // multiply vector by scalar
    for j : 1..3:
        dst.col[i] += lhs.col[i] * rhs_col[i][j] // multiply vector by scalar & add

मैट्रिक्स गुणन वास्तव में दाहिने हाथ की ओर के ऑपरेंड के कॉलम वैक्टर में एक परिवर्तन लागू कर रहा है। अब, परिवर्तन को या तो डॉट उत्पादों के एक समूह के रूप में देखा जा सकता है (भ्रमित करने वाला तरीका जिसे हम आमतौर पर कलम और कागज के साथ उपयोग करते हैं), या गंतव्य स्थान के अक्ष वैक्टर के रैखिक संयोजन के रूप में = बाईं ओर के कॉलम वैक्टर संकार्य।

@Globegitter वाह यह एक शानदार शुरुआत है! मैं Firefox Nightly प्राप्त करने जा रहा हूं ताकि मैं नई शाखा के साथ भी प्रयोग कर सकूं!

@Globegitter मुझे अच्छा लगता है जब कोई आगे बढ़ता है और जब वे उस पर विश्वास करते हैं तो कुछ करते हैं। कोड अलग-अलग दृष्टिकोणों को चर्चा की तुलना में तेज़ी से सुलझाता है।

जहां पॉलीफिल की तुलना में मूल कार्यान्वयन स्पष्ट रूप से ~ 20 गुना तेज है

यह देखने में भी दिलचस्पी होगी कि गैर-सिम की तुलना में पॉलीफिल कितना धीमा है

मैं Firefox Nightly प्राप्त करने जा रहा हूं ताकि मैं नई शाखा के साथ भी प्रयोग कर सकूं!

प्रयोगात्मक और asm.js को about:flags . में स्विच करके एज में इसे आज़माने में सक्षम होना चाहिए

@Globegitter मुझे लगता है कि आपका संपादक अंतर आ रहा है: https://github.com/Globegitter/three.js/commit/d835ca3a22eed4ed4603534773ae55c29d5a8026

मैंने देखा है कि आप एक साइड कार के रूप में SIMD प्रकार बना रहे हैं:

https://github.com/Globegitter/three.js/commit/8ed9c1d351a3b0587a1f05051922d271d79f642d

क्या मैं सुझाव दे सकता हूं कि आप वेक्टर 3 एक्स, वाई, जेड को गेटटर/सेटर्स में बदल दें और केवल फ्लोट 32x4 स्टोर करें? मुझे लगता है कि कम बदलावों के साथ इस तरह के दृष्टिकोण को लागू करना बहुत आसान हो सकता है।

मैं गुणों को परिभाषित करने के सर्वोत्तम तरीके के बारे में निश्चित नहीं हूँ, लेकिन mrdoob यहाँ कुछ ऐसा करता है:

https://github.com/mrdoob/three.js/blob/5c7e0df9b100ba40cdcaaf530196290e16c34858/examples/js/wip/proxies/ProxyVector4.js#L18

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

https://code.google.com/p/bullet/source/browse/trunk/src/vectormath/sse/

@bhouston , इन नोटों के लिए धन्यवाद। मैं यह देखने के लिए सीधे वहां जा रहा था कि मैं कुछ घंटों में तीन और सिम के साथ ज्यादा काम किए बिना कितनी दूर पहुंचूंगा (हम इसे अपनी अधिकांश परियोजनाओं में उपयोग करते हैं)। तो तीन जानने वाले किसी व्यक्ति की यह प्रतिक्रिया वास्तव में सराहनीय है। और हाँ, इसे मेरे संपादक में बंद कर देना चाहिए।

@tschw मैट्रिक्स/वेक्टर गणित पर नोट के लिए धन्यवाद! तुम सही हो यह बेहतर है।

@Globegitter यहाँ एक वस्तु के प्रोटोटाइप पर सेटर/ https://github.com/mrdoob/three.js/blob/master/src/core/Object3D.js#L83

ES2015 पर काम करने पर कुछ सेंट (मुख्य रूप से नोड में)

• ऐसे स्थान हैं जहां जावास्क्रिप्ट इंजन (जैसे। वी 8) को ईएस 6 सुविधाओं को अनुकूलित करने के लिए पकड़ने की जरूरत है
• मेरे अनुभव कोड से जैसे let x = 1, y = 2 v8 को अपॉप्टिमाइज कर देगा, हालांकि मुझे उम्मीद है कि v8 अंततः इसका समर्थन करेगा
• ES5 में ट्रांसपिल्ड कोड ES6 कोड की तुलना में धीमा चलाया जा सकता है (यही कारण है कि मैं> नोड 4 में केवल समर्थित ES6 सुविधाओं का उपयोग करना पसंद करता हूं, जो कि आयात निर्यात प्रणाली को छोड़कर लगभग सब कुछ है)
• मानचित्र और सेट प्रदर्शन जीत हैं
• कक्षाएं अच्छी हैं
• बैबेल का उपयोग करना आपके वर्कफ़्लो के लिए एक दर्द हो सकता है, शायद ES6 का उपयोग पूरी तरह से सिंटैक्स शुगर के लिए करने पर प्रयास के लायक नहीं है

आधे साल पहले मैंने कुछ तीन.जेएस फ़ंक्शन (4x4 मैट्रिक्स गुणा, वेक्टर 4 इत्यादि) को सिम में परिवर्तित कर दिया था और आप उन्हें आजमा सकते हैं। कुछ बिंदु पर यह एक बुकमार्कलेट के रूप में काम करता था लेकिन अब नवीनतम तीन संस्करण के साथ काम करने के लिए रीफ्रेश की आवश्यकता हो सकती है

• Firefox Nightly मूल SIMD आउट ऑफ़ द बॉक्स का समर्थन करता है
• ध्वज के साथ क्रोम --js-flags="--harmony-simd" SIMD के JS पॉलीफिल का समर्थन करता है, इसलिए यह गैर-simd संस्करण की तुलना में धीमा होने वाला है। कम से कम आप जांच सकते हैं कि क्या यह काम करता है और प्रयोग करता है!

350% प्रदर्शन लाभ एक झूठ है :)

मैंने वेक्टर 3 का हिस्सा भी पोर्ट किया है लेकिन यह टिप्पणी की गई है।

https://github.com/DVLP/three.turbo.js

संपादित करें: मेरे पास मेरी हार्ड ड्राइव पर कहीं अधिक अद्यतित संस्करण है, इसलिए मैं जल्द ही इस प्रोजेक्ट को अपडेट करूंगा

उस पर +1 देखना और घूरना बहुत बढ़िया है।
क्या बढ़िया होगा एक प्रणाली जो प्रदर्शन की जांच करती है और उक्त प्रदर्शन के आधार पर ऐसी सुविधाओं को सक्षम या अक्षम करती है।

क्या बढ़िया होगा एक प्रणाली जो प्रदर्शन की जांच करती है और उक्त प्रदर्शन के आधार पर ऐसी सुविधाओं को सक्षम या अक्षम करती है।

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

हम Matrix4 के multiplyMatrices() SIMD संस्करण करके शुरुआत कर सकते हैं क्योंकि यह वर्तमान में जटिल दृश्यों में सबसे अधिक कहा जाने वाला तरीका है।

https://github.com/mrdoob/three.js/blob/dev/src/math/Matrix4.js#L383 -L419

@mrdoob यहाँ देखो यह हो गया है।
https://github.com/DVLP/three.turbo.js/blob/master/src/three.turbo.js

बुकमार्कलेट के रूप में प्रयास करें:
javascript:(function(){var script=document.createElement('script');script.src='//rawgit.com/DVLP/three.turbo.js/master/src/three.turbo.js';document.head.appendChild(script);})()

कोड का टुकड़ा जिम्मेदार

THREE.Matrix4.prototype.multiplyMatrices = function(a, b) {
    var ae = a.elements,
      be = b.elements,
      tb = this.elements,
      arr1 = SIMD.Float32x4.load(ae, 0),
      arr3 = SIMD.Float32x4.load(ae, 4),
      arr5 = SIMD.Float32x4.load(ae, 8),
      arr7 = SIMD.Float32x4.load(ae, 12),
      arr2,
      arr4,
      arr6,
      arr8,
      res;
    // calculated version
        for (var i = 0; i < 4; i++) {
            arr2 = SIMD.Float32x4.splat(be[i * 4]);
            arr4 = SIMD.Float32x4.splat(be[i * 4 + 1]);
            arr6 = SIMD.Float32x4.splat(be[i * 4 + 2]);
            arr8 = SIMD.Float32x4.splat(be[i * 4 + 3]);
            res = SIMD.Float32x4.add(SIMD.Float32x4.add(SIMD.Float32x4.mul(arr1, arr2), SIMD.Float32x4.mul(arr3, arr4)), SIMD.Float32x4.add(SIMD.Float32x4.mul(arr5, arr6), SIMD.Float32x4.mul(arr7, arr8)));
            SIMD.Float32x4.store(tb, i * 4, res);
          }
}

जब मैं इस आधे साल पहले परीक्षण कर रहा था तो मैंने देखा कि "फॉर" लूप वाला संस्करण कम से कम तेज़ था। इसलिए मेरी छोटी लाइब्रेरी में लूप पर टिप्पणी की गई है और हार्डकोडेड संस्करण मौजूद है।

"उलटा" शाखा में और भी कार्य हैं
https://github.com/DVLP/three.turbo.js/blob/inverse/src/three.turbo.js

प्रदर्शन अंतर क्या है?

https://jsfiddle.net/tk6zx5dm/6/

निर्भर करता है। रात्रि में जब गणनाओं की संख्या कम (<1000) होती है तो परिणाम 3 गुना धीमा होता है। जब गणनाओं की संख्या १०००० से अधिक होती है तो गति ~ ४०% तेज होती है

क्रोम में --js-flags="--harmony-simd" ध्वज सक्षम के साथ कोई वास्तविक सिम नहीं है, लेकिन एक जावास्क्रिप्ट पॉलीफिल है, इसलिए स्पष्ट रूप से गति कई गुना धीमी है।

परीक्षण के लिए एक अच्छी जगह क्रॉसवॉक परियोजना (क्रोमियम पर आधारित) होगी। उनके पास Android के लिए वास्तविक SIMD है, इसलिए इस JSFiddle से कोड के साथ एक प्रोजेक्ट बनाने के लिए यह एक दिलचस्प प्रयोग हो सकता है कि परिणाम क्या होगा।

हो सकता है कि आप सिमड पॉलीफिल को अपने उदाहरण पृष्ठों पर किसी भी तरह शामिल न करना चाहें। लोगों के लिए उन्हें आज़माना थोड़ा अधिक सुविधाजनक है। कंसोल में एक लाइन लॉग करें या जब कोई देशी उपलब्ध न हो तो स्क्रीन पर कुछ टेक्स्ट डालें (पॉलीफिल शायद कुछ संकेत छोड़ देता है कि यह सक्षम है)।

मैं कल्पना नहीं कर सकता कि क्रोम सिर्फ जेएस सिम पॉलीफिल को --js-flags="--harmony-simd" साथ क्यों लोड करेगा, इसका कोई मतलब नहीं है जब यह पहले से ही उपयोगकर्ता भूमि में किया जा सकता है ?! इसका क्या फायदा। हो सकता है कि वे धीरे-धीरे सामान डालना शुरू कर दें। आपने यह कहां पढ़ा कि वास्तव में ध्वज के साथ क्या हो रहा है, कोई अच्छा लिंक? यहाँ "विकास में" लग रहा है https://www.chromestatus.com/features/5757910432874496

संपादित करें: वास्तविक विषय के लिए: मैं कल्पना करता हूं कि इस सामान को तीन.जेएस में रखना बहुत कठिन है यदि कुछ वस्तुओं से लेकर बहुत सारी वस्तुओं तक परफ सभी जगह है। यदि सभी कार्यान्वयन 1 से एन वस्तुओं के साथ एक पूर्ण सुधार दे सकते हैं, तो यह पता लगाया जाना चाहिए और जहां यह समझ में आता है वहां उपयोग किया जाना चाहिए। यदि मूल निहितार्थ असंगत हैं, तो मुझे पूरी चीज कहीं भी नहीं दिख रही है, इसलिए इस पर काम करने की जहमत क्यों उठाई जाए, कुछ अधिक उत्पादक पर देव घंटे बिताएं।

तीन परिपक्व होने पर इस पर कूद सकते हैं, या यह मामला है कि तीन.जेएस समर्थन ब्राउज़र कार्यान्वयन को बेहतर करने के लिए प्रेरित कर सकता है? मुझे लगता है कि अवास्तविक इंजन और अन्य सिमुलेशन/गणित उपयोग के मामले ब्राउज़र विक्रेताओं के लिए प्रेरणा शक्ति होंगे, विशेष रूप से कितने libs सुविधा का उपयोग करना चाहते हैं। लेकिन किसे पता।

कल्पना नहीं कर सकता कि क्रोम सिर्फ जेएस सिम पॉलीफिल को --js-flags="--harmony-simd" के साथ क्यों लोड करेगा

मुझे लगता है कि यह एक सामान्य प्रथा है कि ब्राउज़र इसे इस तरह से करते हैं, ताकि उपयोगकर्ता चीजों का परीक्षण करना शुरू कर सकें। उदाहरण के लिए, अगर मैं इसे सही ढंग से समझता हूं, तो शुरुआत में ब्राउज़र में WASM को इस तरह पेश किया जाएगा।

सभी तर्क जो अनिवार्यता का समर्थन करते हैं कि एक सेंचुरियन की आवश्यकता है। प्रदर्शन की वास्तविक समय की निगरानी जो सुविधाओं को सक्षम या अक्षम कर सकती है और इष्टतम प्रदर्शन निर्धारित कर सकती है। तो कैमरा दूरी आदि के आधार पर छाया मानचित्र घनत्व भी बदलना चाहिए। वैसे भी मुझे पता है कि आम सहमति ने फैसला किया है कि यह एक तीसरा पक्ष उपकरण होगा और इसकी आवश्यकता नहीं होगी। फिर भी मैं केवल उस बिंदु को चेतन में रखना चाहता हूँ यदि अवचेतन मन नहीं है।
हो सकता है कि आप सिर्फ पॉलीफिल की जांच कर रहे हों और सिम को अक्षम कर रहे हों लेकिन फिर से एफपीएस सभी को बताता है। उपयोगकर्ता/ऐप विशिष्ट वरीयता के रूप में क्या सक्षम या अक्षम करना है इसकी प्राथमिकताएं सबसे अच्छी होती हैं। सुनने के लिए धन्यवाद! मैं निकट भविष्य में बेहतर तेजी से जीएल की उम्मीद कर रहा हूं। आइए बाकी को मात देने के लिए तैयार रहें।

ऐसा लगता है कि सिम को डेटा लोड करने की प्रक्रिया ओवरहेड बना रही है जो नाइटली में सिम का उपयोग करने के लाभ को खारिज कर देती है। मैं क्रोम में प्रदर्शन के बारे में बहुत उत्सुक हूं लेकिन असली सिम के साथ नवीनतम क्रोमियम यहां है http://peterjensen.github.io/idf2014-simd/
ये पुराना है।

अद्यतन:
अब SIMD एज में भी काम करता है। आप इसके बारे में: झंडे पर जाकर और "प्रयोगात्मक जावास्क्रिप्ट सुविधाओं को सक्षम करें" (एज को पुनरारंभ करें) की जांच करके इसे सक्षम कर सकते हैं।
सुनिश्चित नहीं है कि यह असली सिम या पॉलीफिल है। यह परीक्षण मेरी मशीन पर ~ ४०% धीमी SIMD प्रदान करता है:/ https://jsfiddle.net/tk6zx5dm/6/

मैट्रिक्स 4 ऑब्जेक्ट में कैश किए गए सिमड ऑब्जेक्ट्स के साथ परीक्षण की भिन्नता, सुनिश्चित नहीं है कि यह कभी भी उपयोगी होगा
https://jsfiddle.net/tk6zx5dm/15/
दिलचस्प बात यह है कि सिमड ऑब्जेक्ट्स के साथ कोड कैश्ड क्रोम में भी _कभी-कभी_ तेज होता है जो पॉलीफिल सिमड (...? अजीब) का उपयोग कर रहा है।

THREE.Matrix4.prototype.multiplyMatrices = function(a, b) {
  var i = 4;
  while(i--) {
    SIMD.Float32x4.store(this.elements, i * 4, 
      SIMD.Float32x4.add(
        SIMD.Float32x4.add(
          SIMD.Float32x4.mul(
            a.cacheSIMDRow1,
            b.cacheSIMDSplat[i * 4]
          ),
          SIMD.Float32x4.mul(
            a.cacheSIMDRow2,
            b.cacheSIMDSplat[i * 4 + 1]
          )
        ),
        SIMD.Float32x4.add(
          SIMD.Float32x4.mul(
            a.cacheSIMDRow3,
            b.cacheSIMDSplat[i * 4 + 2]
          ), 
          SIMD.Float32x4.mul(
            a.cacheSIMDRow4,
            b.cacheSIMDSplat[i * 4 + 3]
          )
        )
      )
    );
  }
}

कैशिंग - शायद हर अपडेटमैट्रिक्स() पर निष्पादित किया जाना चाहिए जो अंत में पूरे समाधान को धीमा कर सकता है

THREE.Matrix4.prototype.updateSIMDCache = function() {
  this.cacheSIMDRow1 = SIMD.Float32x4.load(this.elements, 0);
  this.cacheSIMDRow2 = SIMD.Float32x4.load(this.elements, 4);
  this.cacheSIMDRow3 = SIMD.Float32x4.load(this.elements, 8);
  this.cacheSIMDRow4 = SIMD.Float32x4.load(this.elements, 12);

  if(!this.cacheSIMDSplat) {
    this.cacheSIMDSplat = [];
  }
  for(var i = 0; i < 16; i++) {
    this.cacheSIMDSplat.push(SIMD.Float32x4.splat(this.elements[i]));
  }
};

मुझे उत्सुकता है कि क्या ES6 शैली पर दोबारा गौर किया गया है? एक संयोजक को चलाए बिना पूरा कोड अभी अनुपयोगी है, तो क्यों न बेबेल भी चलाएं और जहां उपयुक्त हो वहां ES6 सामान का उपयोग करना शुरू करें?

एक संयोजक को चलाए बिना पूरा कोड अभी अनुपयोगी है, तो क्यों न बेबेल भी चलाएं और जहां उपयुक्त हो वहां ES6 सामान का उपयोग करना शुरू करें?

मुख्य रूप से बेबेल उत्पादित कोड के प्रदर्शन प्रभाव पर परीक्षणों की कमी के कारण। साथ ही, मैंने सुना है कि V8 let/const के बजाय var का उपयोग करते समय तेज़ कोड उत्पन्न करता है।

एफवाईआई : मैंने हाल ही में दिया है जो "खुद को ईएस सुविधाओं तक सीमित करता है जिसे कॉम्पैक्ट, प्रदर्शन करने वाले ईएस 5 में संकलित किया जा सकता है"।

इस लिंक के नीचे वर बनाम लेट इन लूप्स को समझाने में मदद करता है
http://stackoverflow.com/questions/21467642/is-there-a-performance-difference-between-let-and-var
व्यक्तिगत रूप से मैं ब्राउज़र को हिट करने के लिए कोई भी ट्रांसपिलर समाधान की प्रतीक्षा नहीं कर रहा हूं। जैसे 'प्रतीक्षा' के लिए जल्द ही बेहतर है, लेकिन अभी के लिए इसे इस तरह लिखा जाना चाहिए और एक ट्रांसपिलर के माध्यम से चलाया जाना चाहिए, लेकिन अगर यह क्रोम में काम करता है ?! तो अन्य ब्राउज़रों के लिए परीक्षण? मैं कहता हूँ 'उन्हें केक खाने दो... या क्रोम का इस्तेमाल करो।' (मेरी पसंदीदा अभिव्यक्ति)।
मुझे लगता है कि 'चलो' का उपयोग किया जाना चाहिए यदि यह उस स्थिति में है जहां यह अधिमानतः परीक्षणों के माध्यम से ऐसा करने के लिए बेहतर साबित होता है।
मुझे लगता है कि यह ऐसा है जैसे स्कोपिंग से बचने के लिए 'var' फहराया जाता है, लेकिन आप इसे चाहते हैं और फिर 'लेट' सबसे अच्छा है। मुझे लगता है/उम्मीद है कि 'चलो' को कुछ स्थितियों में भी आपकी याददाश्त को छोटा रखना चाहिए।

ट्रांसपिल्ड कोड कभी भी हाथ से अनुकूलित जितना तेज़ नहीं होगा। यह शर्म की बात है कि जेएसपीआरएफ नीचे है। मैं इसे Google से अधिक बार देखता था।
संपादित करें: JSPerf.com नीचे नहीं है! एक साल तक काम नहीं करने के बाद मैंने मान लिया कि यह हमेशा के लिए मर चुका है
let मेरे क्रोम कैनरी में var से 3x धीमा: https://jsperf.com/let-vs-var-performance/14
फ़ायरफ़ॉक्स और एज में गति में कोई अंतर नहीं है लेकिन क्रोम सबसे महत्वपूर्ण है।
क्या कोई सफारी में परीक्षण कर सकता है?

कक्षाएं बहुत अच्छी और आधुनिक लगती हैं! क्या किसी को पता है कि यह पहले से ही शेड्यूल पर है?

@ रुबिनहुआंग 9239 मैंने किसी को भी इसे

मेरे क्रोम कैनरी में var से 3x धीमा होने दें: https://jsperf.com/let-vs-var-performance/14

इसके लायक क्या है, let और const अब उस परीक्षण का उपयोग करके क्रोम 66, फ़ायरफ़ॉक्स 59 और एज 42 पर मेरे लिए var से थोड़ा तेज हैं।

मुझे लगता है कि कक्षाओं पर स्विच करना बहुत सीधा होना चाहिए - काम का मुख्य थोक रोलअप को अपनाना था जो कुछ समय पहले किया गया था। मुझे आश्चर्य नहीं होगा कि एक नायक कुछ घंटों में थ्रीजेएस में कक्षाएं लागू कर सकता है।

वैसे तो बहुत सारी कक्षाएं हैं, इसलिए यदि आप इसे मैन्युअल रूप से करते हैं तो शायद इसमें 8 घंटे लगेंगे।

हो सकता है कि छोटी शुरुआत करें और पहले गणित की कक्षाओं को बदलें और पीआर करें। अगर वह काम करता है, तो दूसरों के लिए आगे बढ़ें।

@looeee यह एक साल से अधिक हो गया है, इसलिए कोई आश्चर्य की बात नहीं है कि ES6 प्रदर्शन के साथ पकड़ने में कामयाब रहा

2019 अंतत: उदाहरणों/दस्तावेज़ों में कुछ ES6 कोड अपनाने का वर्ष है, है ना @mrdoob? मैं

ES6 काफी समय से मानक रहा है, नए डेवलपर ES6 सीखते हैं। इसके अलावा, हम उदाहरणों में IE11 का समर्थन करना बंद कर सकते हैं जैसा कि आप लोगों ने #16220 में चर्चा की थी, कौन से डेवलपर IE11 का उपयोग करते हुए तीन.js उदाहरणों को देखते हैं? मैं

मुझे लगता है कि नवागंतुकों के लिए कोड को सरल बनाने के लिए सबसे आवश्यक विशेषताएं कक्षाएं और टेम्पलेट स्ट्रिंग हैं, जबकि अब डिफ़ॉल्ट कॉन्स्ट/लेट को नहीं भूलना है।

अगर हम शुरू करने का फैसला करते हैं तो मैं योगदान दे सकता हूं।

क्रमशः। आइए अभी के लिए three.module.js का उपयोग करने के लिए उदाहरणों को अपडेट करके प्रारंभ करें।

क्रमशः। आइए अभी के लिए तीन.मॉड्यूल.जेएस का उपयोग करने के लिए उदाहरणों को अपडेट करके शुरू करें।

इस चरण को कुछ समय के लिए पूरा किया गया है। शायद यह आधिकारिक तौर पर अगले चरण पर जाने का समय है?

दो उम्मीदवार:

1. कॉन्स्ट/लेट
2. कक्षाओं

चूंकि कुछ समय के लिए बॉक्स ज्यामिति में कक्षाओं का उपयोग किया जा चुका है, इसलिए मैं पहले ऐसा करने के लिए वोट करता हूं। या हम दोनों एक ही समय में कर सकते थे।

संबंधित: #11552, #18863

अगर मैं सही समझता हूं, तो मुद्दा यह है कि हम कुछ भी ES6 कक्षाओं में परिवर्तित नहीं कर सकते हैं यदि इसे उदाहरणों द्वारा बढ़ाया जाता है, जब तक कि उदाहरण भी परिवर्तित नहीं हो जाते। और इसका मतलब यह हो सकता है कि examples/js के समाप्त होने तक प्रतीक्षा करना? जब तक हम पुष्टि नहीं कर सकते कि modularize स्क्रिप्ट कक्षाओं का समर्थन करेगी, examples/js फ़ाइलों को उनकी मूल कक्षाओं के साथ ही कनवर्ट करने के लिए।

जैसा कि मैं इसे समझता हूं, examples/js सभी अतिरिक्त सुविधाओं की तरह है जो कम-से-कम शांत हैं, लेकिन अगर हम सभी को मुख्य src/... में जोड़ दिया जाए तो यह अनुपात से बाहर हो जाएगा। स्वाभाविक रूप से प्रश्न का उत्तर है 'क्या हम सामान्य रूप से बनाए गए x, y, z के उदाहरण/स्क्रिप्ट प्रदान करते हैं?'। मुझे लगता है कि तीन.जेएस का जवाब ज्यादातर हां है लेकिन वेबसाइट के भीतर शैक्षिक सामग्री के रूप में है। examples/js हटाना उस समय सवाल से बाहर लगता है। हालांकि शायद मैंने गलत समझा है कि कैसे examples/js को संदर्भित/उपयोग किया जाता है मुझे बताएं।

examples/js को केवल वेबसाइट/शैक्षिक के रूप में छोड़ने से उस फ़ोल्डर का हिस्सा छूट जाता है जो कि समुदाय स्क्रिप्ट/सामग्री/प्रोजेक्ट/अन्य हो सकता है जिसे लोग साझा करना चाहते हैं लेकिन मुझे कहीं इस बात की जानकारी नहीं है कि यह दोगुना हो रहा है वह।

मैंने खुद को पीछे कर लिया।

जब तक उदाहरण भी परिवर्तित नहीं हो जाते।

मुझे यह हमारे अगले सर्वश्रेष्ठ अंतरिम कदम के रूप में ध्वनि पसंद है।

@निश्चित रूप से हम examples/js में कार्यक्षमता को नहीं हटा रहे हैं, ध्यान देने योग्य दो निर्देशिकाएं हैं:

• examples/js/*
• examples/jsm/*

पहले में लीगेसी फाइलें होती हैं, बाद में उन फाइलों से उत्पन्न ES मॉड्यूल समान कार्यक्षमता के साथ होते हैं। हम अंततः पहले को हटा देंगे। रूपांतरण करने वाली स्क्रिप्ट वर्तमान में ES कक्षाओं का समर्थन नहीं करती है। इसलिए जब तक इसे हटाया नहीं जाता है, तब तक examples/js फ़ाइलों को ES कक्षाओं में परिवर्तित नहीं किया जा सकता है। उनमें से कुछ src/ में फ़ाइलों का विस्तार करते हैं, और आप ES कक्षाओं का उपयोग किए बिना ES कक्षाओं का विस्तार नहीं कर सकते हैं, इसलिए यह एक अवरुद्ध निर्भरता है।

आह, पिछली टिप्पणी से भ्रमित था

और इसका मतलब यह हो सकता है कि उदाहरण/जेएस खत्म होने तक प्रतीक्षा करें?

अब समझ में आता है।

Modularize.js मुझे मेरे शुरुआती प्रोजेक्ट की याद दिलाता है जो मुझे यहां लाया। कन्वर्टर । मैंने यहां ES6 कक्षाओं में जाने के बारे में टिप्पणियां देखीं, इसलिए मैंने सोचा कि मैं इसके बजाय यहां कूद जाऊंगा।

तो अगर examples/js किसी तरह से src का विस्तार करता है तो दोनों को एक ही समय में ES6 कक्षाओं में परिवर्तित करने की आवश्यकता होती है
या...
जब तक यह कक्षाएं/ईएस 6 उत्पन्न नहीं करता तब तक मॉड्यूलरलाइज पर काम करें?

हम कुछ भी ES6 कक्षाओं में परिवर्तित नहीं कर सकते हैं यदि इसे उदाहरणों द्वारा बढ़ाया गया है

कोर में अभी भी बहुत सी चीजें हैं जो उदाहरणों में विस्तारित नहीं हैं, हम इसके साथ शुरू क्यों नहीं करते?

यह मुझे ठीक लगता है।

@ Mugen87 क्या ES वर्ग परिवर्तन को अवरुद्ध करने वाला कुछ और था, या बस?

कोर में अभी भी बहुत सी चीजें हैं जो उदाहरणों में विस्तारित नहीं हैं, हम इसके साथ शुरू क्यों नहीं करते?

लिपियों की सूची उदाहरणों द्वारा विस्तारित नहीं की गई ।

संपादित करें: सूची अपडेट कर दी गई है!

अवरोधक इस तरह के खंड हैं:

https://github.com/mrdoob/three.js/blob/6865b8e6367d0ce07acbacfae6663c4cce3ac21e/examples/js/loaders/ColladaLoader.js#L6 -L12

https://github.com/mrdoob/three.js/blob/6865b8e6367d0ce07acbacfae6663c4cce3ac21e/examples/js/cameras/CinematicCamera.js#L38 -L39

https://github.com/mrdoob/three.js/blob/6865b8e6367d0ce07acbacfae6663c4cce3ac21e/examples/js/controls/OrbitControls.js#L1149 -L1150

THREE.<class>.call और Object.create( THREE.<class> का उपयोग सबसे संभावित पैटर्न होगा। जिसका अर्थ यह होगा कि लोडर, EventDispatcher, और PerspectiveCamera (शायद कई अन्य लोगों के बीच) को अभी तक कक्षाओं में परिवर्तित नहीं किया जा सकता है।

https://github.com/mrdoob/three.js/commit/1017a5432eede4487436d6d34807fda24b506088

ठीक है, मुझे लगता है कि हम let और const से src/ शुरुआत कर सकते हैं।

@ निश्चित रूप से शायद यह ऐसा कुछ है जिसके साथ आप मदद करना चाहेंगे?

नरक हाँ!

मैं सिर्फ एक चिंता उठाना चाहता था कि यदि आप हॉट कोड लोड कर रहे हैं तो मेरा डर है कि समस्या पैदा होगी। यदि यह सभी जावास्क्रिप्ट में सच है कि ऑब्जेक्ट्स पूरी तरह से कॉन्स्ट को ओवरराइट करते हैं तो कोई समस्या नहीं है। हां, अगर वे नहीं करते हैं, तो सभी कॉन्स्ट का कभी भी उपयोग नहीं किया जाना चाहिए। मैं ऑब्जेक्ट स्ट्रक्चर को उन ऑब्जेक्ट पेड़ों (जैसे संरचनाओं) की चाबियों को असाइन किए गए कोड फ़ंक्शंस के साथ मर्ज करता हूं, इसलिए मैं अधिकांश भाग के लिए let या const का उपयोग करने की आवश्यकता से बचता हूं।
वैसे भी यह सोचने के लिए कुछ है और मेरा मूल रूप से मानना ​​​​है कि कॉन्स का कभी भी उपयोग नहीं किया जाना चाहिए और वास्तव में अनावश्यक हैं। मुख्य रूप से हॉटकोड लोडिंग के साथ मेरी चिंताओं के लिए।
फिर भी मुझे लगता है कि वे उतने स्थिर नहीं हैं जितना आप सोचते हैं, इसलिए हो सकता है कि कोई ऐसा व्यक्ति जो इसे अधिक समझता हो, यह समझा सकता है कि यह आयात रीलोडिंग या जो कुछ भी है, के साथ एक अर्थहीन चिंता है। आपके विचार और इनपुट के लिए धन्यवाद।
चलो 'चलो' हो! आखिरकार।

क्रॉकफोर्ड ने कहा कि var एक बड़ी गलती थी, लेकिन इसे बदला नहीं जा सकता था इसलिए 'let' बनाया गया था, लेकिन var को त्रुटिपूर्ण माना जाता है और 'let' का कोड var के लिए एक फिक्स होना चाहिए था, लेकिन यह कुछ खराब कोड वाले किनारे के मामलों को छोड़ देता जंगली में दुबका हुआ। सख्त मोड और उत्थापन इस विषय के आसपास के मुद्दे हैं।

@MasterJames कॉन्स्ट का उपयोग करते समय हॉट

मैं एक रिएक्ट वातावरण में काम करता हूं और हॉट रीलोडिंग वहां का आदर्श है, साथ ही साथ कॉन्स और लेट, जो आजकल मानक हैं।

मैं सहमत हूं, यह हॉट रीलोडिंग में हस्तक्षेप नहीं करेगा। शायद आपने const के साथ वस्तुओं को अपरिवर्तनीय बनाने के लिए गलत किया है Object.freeze ? हम ऐसा करने की योजना नहीं बना रहे हैं।