Pixi.js: जीएल-मैट्रिक्स माना जाता है?

1) SIMD मर चुका है। https://github.com/rwaldron/tc39-notes/blob/a66df6740eec3358d5e24f81817db99d6ee41401/es8/2017-03/mar-21.md#10if -simdjs-status-update

2) सरल 6 फ़ील्ड "ए, बी, सी, डी, टीएक्स, टीवाई" फ्लोट32एरे (9) मैट्रिक्स से भी बेहतर प्रदर्शन कर रहे हैं। परीक्षणों के लिंक नहीं दे सकते, लेकिन I और @GoodBoyDigital दोनों ने इसे पहले से ही एकीकृत करने का प्रयास किया।

3) जेएस डबल परिशुद्धता करता है, जो बड़े निर्देशांक के साथ काम करने वाले ऐप्स के लिए महत्वपूर्ण है। ग्राफिक्स के लिए "प्रोजेक्शन एक्स ट्रांसफॉर्म" और जेएस पक्ष पर स्प्राइट बेहतर हैं।

मैं v5 में एक Float32Array(9) का उपयोग कर रहा हूं, जो मेरे jsperf परीक्षणों में समान था यदि समान perf नहीं है, और हमें toArray करने और संचालन को स्थानांतरित करने की आवश्यकता से रोकता है।

https://github.com/pixijs/pixi.js/blob/455c059e8d155c1d9a05fc2ece2c02b3bdf8bf84/plugins/core/src/math/Matrix.js

gl-matrix फायदेमंद है क्योंकि इसमें सिम था (जैसा कि इवान ने उल्लेख किया है कि यह एक मृत कल्पना है), लेकिन उनके कार्यान्वयन में भी गिरावट आई है। हम GPU को हिट करने के लिए एक 3x3 मैट्रिक्स ( Float32Array(9) ) चाहते हैं, लेकिन संचालन करते हैं जैसे कि यह गणना समय बचाने के लिए 2D मैट्रिक्स था। gl-matrix पास इसके लिए कोई अच्छा तंत्र नहीं है।

V5 संस्करण स्टोरेज का उपयोग करता है जिसे हम सीधे GPU पर अपलोड कर सकते हैं और साथ ही केवल उन 2D भागों पर काम कर सकते हैं जिनकी हम परवाह करते हैं। यह हमें SharedArrayBuffers और अन्य अनुकूलन का उपयोग करने में सक्षम होने के लिए भी सेट करता है जो हमें वेबवर्कर्स पर अधिक काम करने दे सकता है। हम देखेंगे कि हम इसके साथ कितनी दूर जा सकते हैं।

@englercj मुझे डर है कि हमें लगातार बने रहने के लिए कई जगहों पर Math.found का उपयोग करना होगा। पूर्ण फ्लोट64एरे का प्रयास करें।

मैं इसे Float64Array बनाने की कोशिश कर सकता था, लेकिन फिर भी हमें इसे अपलोड करने के लिए सिंगल-प्रेसिजन में डाउनसाइज करने की आवश्यकता है। यह भी ध्यान रखें, जब हम GPU पर अपलोड करते

मैट्रिक्स अपलोड कभी भी हमारी अड़चन नहीं थी, हम उन जगहों पर "uniform3fv" का उपयोग करते हैं, यह सरल ऑपरेशन नहीं है, और इसके बाद एक ड्रॉकॉल होता है, और ज्यादातर मामलों में, बड़ा बफर अपलोड होता है। हैवी पिक्सी ऐप प्रति फ्रेम लगभग 400 ड्रॉकॉल कर रहा है,

बड़े निर्देशांक के साथ उपयोगकर्ता की समस्याओं का सामना करने के बाद, जब तक हम इसे अपलोड नहीं करते, मैं सब कुछ डबल परिशुद्धता के साथ संग्रहीत करना पसंद करता हूं।

इसके अलावा, "ए, बी, सी, डी, टीएक्स, टीवाई" अंकन "0,1,3,4,6,7" की तुलना में लिखना और पढ़ना आसान है। इसका उपयोग रीढ़ की हड्डी में भी किया जाता है, उनके ऊपर बहुत परिष्कृत परिवर्तन होते हैं। यदि हम मैट्रिक्स पर स्विच करते हैं तो बाद में हमारे कोड की जांच करना इतना आसान नहीं होगा। कुछ लोगों के लिए मैट्रिक्स ऑपरेशंस की कल्पना करना मुश्किल है, लेकिन मैंने उन्हें आसानी से पढ़ा।

यूपीडी. मुझे यह भी लगता है कि यह हमें मैट्रिक्स को परिवर्तित करने से अधिक मदद करेगा: https://github.com/gameofbombs/gobi/blob/master/src/core/math/FlatTransform2d.ts , जो कि "फ्लैट" परिवर्तन है, इसमें सभी आवश्यक फ़ील्ड शामिल हैं मैट्रिक्स की गणना के लिए।

यूपीडी2. लेकिन 3डी ट्रांसफॉर्म के लिए, फ्लोट32एरे(16) बेहतर है और मैं इसके खिलाफ नहीं बोलूंगा।

मेरा वोट उसी को जाता है जो सबसे अच्छा प्रदर्शन करता है। अंतिम बार मैंने इसे सरणियों पर वस्तुओं का उपयोग करके तेज किया था। हालाँकि मुझे 100% यकीन नहीं है कि अगर यह अभी भी सच है, तो शायद यह बदल गया होगा!

3डी के लिए मैं ग्लो-मैट्रिक्स शैली का पक्ष लेता हूं, मुख्य रूप से जब GPU पर सामान बहुत अधिक अपलोड हो जाता है! पिक्सी के साथ आमतौर पर ऐसा नहीं होता है। जेएस भूमि में अधिकांश हेरफेर होता है (उदाहरण के लिए स्प्राइट बैचर)।

https://jsperf.com/obj-vs-array-view-access/1

यहाँ मैंने जो परीक्षण किया है। वस्तु Float32Array की तुलना में धीमी जो दोनों के धीमी रास्ता सामान्य सरणी से होती है। फिर हमें डबल प्रिसिजन और सबसे तेज सीपीयू स्पीड मिलती है और इसे सीधे अपलोड किया जा सकता है।

संपादित करें: ऐसा लगता है कि Array परिणाम एक अस्थायी था, मैं इसे पुन: पेश करने में असमर्थ हूं?

मेरा वोट उसी को जाता है जो सबसे अच्छा प्रदर्शन करता है।
अंतिम बार मैंने इसे सरणियों पर वस्तुओं का उपयोग करके तेज किया था।

वो बहुत रुचिकर है। ऐसा लगता है कि ऑब्जेक्ट पूरी तरह से संख्यात्मक सरणी से तेज़ होंगे, क्योंकि अंतर्निहित वीएम कई अनुकूलन करने में सक्षम होना चाहिए, यह जानकर कि ऑब्जेक्ट सेमेन्टिक्स को काफी हद तक हटा दिया जा सकता है। मैं उत्सुक हूं यदि आपके पास कोई विचार है _why_ वस्तुएं तेज हो सकती हैं?

मेरे COMP से प्रासंगिक परिणाम (i7, Windows 10):

क्रोम 59:

फ़ायरफ़ॉक्स 54.0.1 (32-बिट):

माइक्रोसॉफ्ट एज 40.15063.0.0:

ऐसा लगता है कि Array का मेरा क्रोम परिणाम तेज होना एक अस्थायी था, यह सुनिश्चित नहीं था कि वह क्या था लेकिन अब इसे पुन: पेश करने में असमर्थ है। यह लगभग 50 एम ऑप्स/एस है, लेकिन एक रन पर 500 एम ऑप्स/एस था जो मैंने पहले किया था। अजीब...

किसी भी तरह से, Float32Array सदस्य सभी ब्राउज़रों में ऑब्जेक्ट की तुलना में समान गति या तेज़ होता है। यही कारण है कि मैंने इसे बदल दिया है, यह पहले (या तेज) की तरह ही गति है लेकिन अब हम अपलोड करने के लिए एक सरणी को स्थानांतरित करने और भरने से बचते हैं।

क्या आप कृपया फ्लोट 64 के साथ भी ऐसा कर सकते हैं? :)

मुझे प्रति ड्रॉकॉल के बारे में एक से अधिक मैट्रिक्स ऑपरेशन से अधिक कोड गुणवत्ता की परवाह है।

साथ ही, हम इनवर्ट का ज्यादा इस्तेमाल नहीं करते हैं। अपडेटट्रांसफॉर्म() हमारी समस्या है।

मुझे प्रति ड्रॉकॉल के बारे में एक से अधिक मैट्रिक्स ऑपरेशन से अधिक कोड गुणवत्ता की परवाह है।

Float64Array उच्च कोड गुणवत्ता कैसी है? मैं समझता हूं कि हमें अधिक सटीकता मिलती है, लेकिन मुझे यकीन नहीं है कि मैं इसका पालन करता हूं कि यह इतना महत्वपूर्ण क्यों है, हम वैसे भी एकल-परिशुद्धता को कम करते हैं।

साथ ही, हम इनवर्ट का ज्यादा इस्तेमाल नहीं करते हैं। अपडेटट्रांसफॉर्म() हमारी समस्या है।

यह डेटा स्टोरेज के पढ़ने/लिखने के बेंचमार्किंग कर रहा है, अप्रासंगिक में मूल्यों के बीच किए गए ऑपरेशन।

मुझे प्रति ड्रॉकॉल के बारे में एक से अधिक मैट्रिक्स ऑपरेशन से अधिक कोड गुणवत्ता की परवाह है।

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

यह डेटा संग्रहण के पढ़ने/लिखने का बेंचमार्क है,
अप्रासंगिक में मूल्यों पर किया गया ऑपरेशन।

मुझे लगता है कि तुम दोनों सही हो। यह डेटा स्टोरेज को पढ़ने/लिखने का एक सामान्य बेंचमार्किंग है। लेकिन इवान के पास वास्तव में एक अच्छी बात है; अगर updateTransform() भारी ऑपरेशन है, तो यह देखना मजबूरी होगा।

मुझे सामान्य रूप से सूक्ष्म बेंचमार्क के बारे में चिंता है; इन स्थिर डेटा सेटों के साथ मुझे आश्चर्य होता है कि क्या हम अनजाने में इन परीक्षणों में जावास्क्रिप्ट वीएमएस में संकलक अनुकूलन का लाभ उठा रहे हैं। वास्तविक विश्व परीक्षण चलाना बहुत अधिक ज्ञानवर्धक होगा (सेटअप के लिए अधिक काम करने के तरीके की कीमत पर।)

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

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

मुझे यह भी संदेह है कि जेएस में वीसी गणित के लिए लोगों को एक या दो स्टैंडआर्ट का उपयोग करना संभव है।

Float64Array उच्च कोड गुणवत्ता कैसी है? मैं समझता हूं कि हमें अधिक सटीकता मिलती है, लेकिन मुझे यकीन नहीं है कि मैं इसका पालन करता हूं कि यह इतना महत्वपूर्ण क्यों है, हम वैसे भी एकल-परिशुद्धता को कम करते हैं।

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

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

बड़ी परियोजना के मामले में उपयोगकर्ता को अपनी तरफ से मजबूर करना ठीक है, लेकिन छोटे लोगों के लिए यह सिर्फ एक और सिरदर्द है।

मुझे यह भी संदेह है कि जेएस में वीसी गणित के लिए लोगों को एक या दो स्टैंडआर्ट का उपयोग करना संभव है।

मुझे समझ में नहीं आया कि आपका क्या मतलब है, क्या आप विस्तार से बता सकते हैं?

मुझे समझ में नहीं आया कि आपका क्या मतलब है, क्या आप विस्तार से बता सकते हैं?

मैं नहीं कर सकता, यह मेरे लिए बहुत ज्यादा है।

हमारे पास निम्न-स्तरीय अनुकूलन दोनों में अलग-अलग अनुभव वाले लोग हैं। और भाषा निर्माण, डीएसएल-एस। हमें एक ऐसे स्टैंडआर्ट की जरूरत है जो हम सभी को किसी न किसी स्तर पर संतुष्ट करे।

पिछले दो वर्षों में, मैंने अलग-अलग ट्रांसफ़ॉर्म के साथ पिक्सी (v3 और v4 के लिए) के दो कांटे बनाए, मैं "पिक्सी-स्पाइन" के साथ काम कर रहा हूं, जिसका अपना उन्नत ट्रांसफॉर्म है और मैं तीसरा कांटा बना रहा हूं। "पिछले इवान" दृष्टिकोण से, सरणी सबसे अच्छी है क्योंकि इसका सबसे सरल रूप है और "ग्ल-मैट्रिक्स" है।

मैं @ivanpopelyshev से सहमत

हो सकता है कि हम इसे Float64Array के रूप में संग्रहीत करें, और अपलोड करते समय इसे Float32Array में कॉपी करें। यह कम से कम हमें एक टाइप-एरे का उपयोग स्टोरेज बैकिंग के रूप में करने देता है जिसे वेबवर्कर से/को कॉपी करना आसान होना चाहिए।

Float64Array यह तब है, मुझे बस उपयोग करना याद रखना होगा (0,1), (3,4), (6,7) एक्स, वाई, अनुवाद के रूप में

सभी दिलचस्प चीजें दोस्तों, मैं हमारे प्रस्तावित समाधान को वास्तविक पिक्सी परिदृश्य में बेंचमार्क करने के लिए उत्सुक हूं - बन्नीमार्क जैसा कुछ।

इस क्षेत्र में मेरा अनुभव यह है कि जब मैंने और @ivanpopelyshev ने पिछली बार बनी मार्क के लिए gl-matrix पर स्विच किया था, तो हमने पाया कि यह काफी धीमी गति से चला (जैसे तीसरा धीमा!)

हालांकि यह थोड़ी देर पहले की बात है और मैं वास्तव में यहां गलत होना पसंद करूंगा!
यदि गति अंतर अब नगण्य है तो मुझे लगता है कि ऊपर प्रस्तावित मार्ग इक्का होगा।

पिक्सी स्पीड है: पी किसी भी समाधान के लिए पूरी तरह से प्रतिबद्ध होने से पहले सुनिश्चित करें कि हम परीक्षण करते हैं।

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

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

क्या कोई ऐसी चीज है जिसमें मैं फिर से मदद कर सकता हूं: यह अद्यतन बनीमार्क? मुझे इसके साथ कुछ समय दान करने में खुशी हो रही है।

मुझे यहां होने वाली पूर्ण सामग्री के साथ-साथ अनुसरण करने में बहुत दिलचस्पी होगी। परिणाम की परवाह किए बिना। यदि सरणी आधारित सामग्री अभी भी बहुत धीमी हो रही है, तो मैं इसके पीछे _why_ के बारे में वास्तव में उत्सुक हूं।

फिर से ध्यान देने योग्य बात: परफ टेस्टिंग...क्रोम के v8 ने हाल ही में (v59 में) v8 में कुछ बहुत ही नाटकीय बदलाव जारी किए जिन्हें टर्बोफैन कहा जाता है। माना जाता है कि इसमें कुछ महत्वपूर्ण प्रदर्शन सुधार हैं।

https://v8project.blogspot.com/2017/05/launching-ignition-and-turbofan.html

टर्बोफैन के मौजूद होने से पहले के संस्करण पर अपडेटेड बनीमार्क को चलाने के लिए दिलचस्प हो सकता है, बस इसके लिए।

@GoodBoyDigital मैंने

https://jsperf.com/obj-vs-array-view-access/1

केवल एज पर ऑब्जेक्ट स्पीड फ्लोट64एरे से मेल खाता है/अधिक है, और यह वास्तव में करीब है।

मैंने इसे अपने एनवी में परीक्षण किया है और मुझे इसी तरह के परिणाम मिलते हैं ... क्या बकवास है ?! फ्लोट 64 सरणी समकक्ष फ्लोट 32 सरणी संचालन की तुलना में काफी तेज क्यों पढ़/लिखेगी? केवल एक चीज जो दिमाग में आती है वह यह है कि 64 बिट फ्लोट शब्द सीमाओं पर संरेखित हो सकते हैं? मैं हैरान हूँ।

प्रस्ताव @mreinstein के लिए धन्यवाद! यदि आप हमें कुछ पूर्ण परीक्षणों के साथ मदद कर सकते हैं जो निश्चित रूप से पूरी बहस को ठंडे कठोर तथ्यों के साथ बिस्तर पर डाल देंगे!

करने के लिए सबसे अच्छी बात फोर्क पिक्सी है और फिर ग्लो -मैट्रिक्स या

फिर एक बार जब हमारे पास एक ट्वीक किया गया संस्करण होता है तो हम यहां परफ का परीक्षण कर सकते हैं: https://pixijs.github.io/bunny-mark/
हम विभिन्न सरणी प्रकारों के साथ गड़बड़ कर सकते हैं।

@englercj कमाल है यार! इन परिणामों को निश्चित रूप से देखना उत्साहजनक है। क्या v5 संस्करण एक ऐसे राज्य के पास है जहां हम बनी मार्क को स्पिन दे सकते हैं?

@mreinstein सिर्फ एक कूबड़, मुझे लगता है कि यह 64 बिट -> 32 बिट से रूपांतरण के साथ हो सकता है
जेएस में एक संख्या के रूप में 64 बिट सही है?

@GoodBoyDigital मुझे लगता है कि शायद आप सही कह रहे हैं। मेरे दोस्त श्रीमती का सहारा लेना गूगल, मैं इस पर ठोकर खाई:

https://stackoverflow.com/questions/15823021/when-to-use-float32array-instead-of-array-in-javascript

शीर्ष रेटेड उत्तर (वर्तमान में 44 वोटों पर) उचित और प्रासंगिक लगता है।

यदि आप कुछ पूर्ण परीक्षणों में हमारी सहायता कर सकते हैं

ठीक है, इसमें मदद करने में खुशी हुई। :)

करने के लिए सबसे अच्छी चीज है फोर्क पिक्सी

@GoodBoyDigital @englercj इस बिंदु से कांटा लगाने के लिए सबसे अच्छी शाखा कौन सी है?

फिर ट्रांसफ़ॉर्म को ग्लो -मैट्रिक्स या बदलें ।
इस उदाहरण के लिए, हमें केवल वास्तव में स्प्राइट बैच को भी काम करने की ज़रूरत है - पूरे इंजन को नहीं!

क्या आप इस पर थोड़ा और विस्तार कर सकते हैं? मैं सिर्फ पूर्ण बेंच चलाने के लिए पूरे इंजन को ग्लो-मैट्रिक्स में परिवर्तित नहीं करना चाहता हूं ... मुझे https://github.com/pixijs/bunny-mark में कोई स्प्राइट बैच सामग्री दिखाई नहीं दे रही है ऐसा प्रतीत होता है PIXI.Container मूल तत्व के रूप में, जिसमें खरगोश जोड़े जाते हैं। क्या आप कह रहे हैं कि मुझे pixi.container, pixi.sprite से शुरू करना चाहिए और वहां से पीछे की ओर काम करना चाहिए ताकि सभी जगहों को खोजने के लिए निर्भरता पेड़ को बदल दिया जा सके जहां ट्रांसफॉर्म सामग्री को प्रतिस्थापन की आवश्यकता हो? यह नहीं कह रहा कि मैं असहमत हूं, बस यह सुनिश्चित करना चाहता हूं कि मेरे पास अनावश्यक काम को कम करने के लिए सही रणनीति है।

अपडेटट्रांसफॉर्म के अंदर दो मैट्रिक्स ऑपरेशन हैं:

1. स्थिति, धुरी, पैमाने, रोटेशन से संरचना - सुधार नहीं किया जा सकता है।
2. मूल मैट्रिक्स द्वारा गुणा - सुधार किया जा सकता है।

मैं Float64Array द्वारा समर्थित पुराने "ए, बी, सी, डी, टीएक्स, टीवाई" प्रोप के साथ मैट्रिक्स क्लास बनाने का सुझाव देता हूं, और अपडेट ट्रान्सफॉर्म को फिर से लिखता हूं। इसके अलावा, @mreinstein ने कोर में रहने के लिए पर्याप्त चीजें

इसलिए उसके पास शाखाओं तक पहुंच है और खेत का निर्माण होता है।

उस तक सभी की पहुंच है, कांटा + पीआर वह सब करता है।

मैं उत्सुक हूं कि आप लोगों को बनी मार्क में किस प्रकार के परिणाम मिलते हैं..जब मैं क्रोम से विभिन्न शाखाओं (देव, रिलीज, अन्य) को डिफ़ॉल्ट 100k बनीज़ के साथ आज़माता हूं तो मुझे लगातार 10-16fps मिलता है। 8.75 से अधिक चल रहे कोड पर एक पूर्ण विश्लेषण करना:

लगभग सारा समय जावास्क्रिप्ट कॉल में व्यतीत होता है।

जावास्क्रिप्ट में बिताए गए इस समय में से शेर का समय वास्तव में Sprite.calculateVertices() में खर्च होता है। TransformStatic.updateTransform() में खर्च की गई

फ़ायरफ़ॉक्स में मुझे फ्रैमरेट के बारे में दोगुना मिलता है, लेकिन बिताए गए समय का टूटना समान है; calculateVertices() दोनों ब्राउज़रों में बहुत अधिक समय लेता है। क्या यह अपेक्षित है? क्या आपको अपने बनीमार्क रनों में समान परिणाम मिल रहे हैं?

यह खरगोशों के लिए अपेक्षित है। और जिस मैट्रिक्स ऑपरेशंस के बारे में हम बात कर रहे हैं वह दो जगहों पर किया जाता है: upateTransform() गुणन के लिए और फ्लश() एक बार प्रति कॉल। यह बड़े पैमाने पर मायने नहीं रखता।

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

यदि यह गलत है, और एफपीएस यह माप नहीं है कि मेरी पिक्सी बिल्ड कितनी अच्छी है, तो मैं किसी दिए गए निर्माण को मापने के लिए किस मानदंड का उपयोग करता हूं?

इसे या तो सीपीयू पर या तो जीपीयू की तरफ से थ्रॉटल किया जा सकता है (यह नहीं दिखाया गया है),

यदि आपके पास एफपीएस 60 से बहुत कम है लेकिन "निष्क्रिय" बड़ा है - इसका जीपीयू।

यदि निष्क्रिय छोटा है, तो इसका सीपीयू।

कैलकुलेट वर्टिस में मैट्रिक्स ऑपरेशन है - मैट्रिक्स द्वारा केवल चार कोनों को गुणा करें।

टीएस कांटा के लिए बस छोटा सा विचार: मैट्रिक्स प्रकारों के लिए इनलाइन गुणों को रूपांतरित करें। इसकी शर्म की बात है कि टीएस के लिए अभी तक उस तरह के परिवर्तन नहीं हुए हैं :(

मुझे लगता है कि यह बैबेल के लिए भी किया जा सकता है यदि हम मैट्रिक्स चर को एनोटेट करने का कोई तरीका ढूंढते हैं।

मुझे समझ नहीं आ रहा है कि अब क्या हो रहा है।

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

मैं यहां सामान्य रूप से पिक्सी के बारे में प्रदर्शन निष्कर्ष निकालने से बचना चाहता हूं क्योंकि मैंने बनी चिह्न को प्रोफाइल किया है। क्रोम में,> प्रोग्राम के कुल समय का 50% Sprite.calculateVertices() (40% ish) में खर्च किया जाता है, इसके बाद TransformStatic.updateTransform() (11% ish) फ़ायरफ़ॉक्स दो बार तेजी से चलता है, लेकिन अनुपात उन 2 कार्यों में बिताया गया समय अभी भी सुसंगत है।

मैं विषय से बहुत दूर जाने से बचना चाहता हूं, लेकिन मैं कहूंगा कि इस बनीमार्क प्रोफाइलिंग में, मुझे लगता है कि es5 गेटर्स/सेटर्स के हमारे उपयोग का क्रोम में perf ड्रॉप के साथ कुछ करना हो सकता है: https: //jsperf.com/es5-getters-setters-versus-getter-setter-methods/10

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

आप @mreinstein को क्या ईमेल

@englercj जो कहता है उसके आधार पर जाहिर तौर पर हम ऐसा नहीं कर रहे हैं। समापन।

बस छोटा सा अपडेट: मेरे पास फ्लोट64एरे पर आधारित https://github.com/pixijs/pixi-projection/blob/master/src/Matrix2d.ts में 3x2 के बजाय 3x3 मैट्रिक्स है।

इस थ्रेड को स्वचालित रूप से लॉक कर दिया गया है क्योंकि इसे बंद करने के बाद हाल ही में कोई गतिविधि नहीं हुई है। कृपया संबंधित बग के लिए एक नया मुद्दा खोलें।