Pixi.js: تعتبر GL مصفوفة؟

1) SIMD ميت. https://github.com/rwaldron/tc39-notes/blob/a66df6740eec3358d5e24f81817db99d6ee41401/es8/2017-03/mar-21.md#10if -simdjs-status-update

2) 6 حقول بسيطة "a، b، c، d، tx، ty" تعمل بشكل أفضل بكثير حتى من مصفوفة Float32Array (9). لا يمكن إعطاء روابط للاختبارات ، لكن أنا و GoodBoyDigital حاولت دمجها بالفعل.

3) تعمل JS بدقة مضاعفة ، وهو أمر بالغ الأهمية للتطبيقات التي تعمل بإحداثيات كبيرة. من الأفضل أن يكون "الإسقاط x التحويل" للرسومات والعفاريت على جانب JS.

أنا أستخدم Float32Array (9) في الإصدار 5 والذي كان مشابهًا في اختبارات jsperf إن لم يكن الأداء نفسه ، ويمنعنا من الحاجة إلى القيام بعمليات الصفوف والتبديل.

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

gl-matrix مفيدًا لأنه يحتوي على SIMD (والتي كما ذكرها Ivan هي مواصفات ميتة) ، ولكن بها عيوب أيضًا في تنفيذها. نريد مصفوفة 3x3 ( Float32Array(9) ) لتصل إلى GPU ، لكننا نقوم بالعمليات كما لو كانت مصفوفة ثنائية الأبعاد لتوفير وقت الحساب. لا يمتلك gl-matrix آلية جيدة لذلك.

يستخدم الإصدار v5 مساحة تخزين يمكننا تحميلها مباشرة إلى وحدة معالجة الرسومات بالإضافة إلى العمل فقط على الأجزاء ثنائية الأبعاد التي نهتم بها. كما أنه يهيئ لنا القدرة على استخدام SharedArrayBuffers والتحسينات الأخرى التي قد تسمح لنا بوضع المزيد من العمل على عمال الويب. سنرى إلى أي مدى يمكننا أن نحققه.

englercj أخشى أنه سيتعين علينا استخدام Math.fround في العديد من الأماكن لنكون متسقين. جرب perf Float64Array.

يمكنني محاولة جعله Float64Array ، ولكن بعد ذلك ما زلنا بحاجة إلى تقليص حجمه إلى دقة مفردة للتحميل. ضع في اعتبارك أيضًا أننا نستخدم حاليًا float32 عندما نقوم بالتحميل إلى وحدة معالجة الرسومات . لذلك نقوم بالحسابات المزدوجة ، ثم نقطعها إلى مفردة. قد يكون هذا أكثر دقة من القيام بكل شيء منفردًا ، ولكن أود أن أحاول أن أكون متسقًا مع نوع البيانات التي نحملها. لسوء الحظ ، هذا يعني الدقة المفردة حتى GL 4.0 ، و WebGL 2 هو GL ES 3.0 فقط:

تحميل المصفوفة لم يكن أبدًا عنق الزجاجة لدينا ، فنحن نستخدم "uniform3fv" في تلك الأماكن ، وهي ليست عملية بسيطة ، ويتبعها drawCall ، وفي معظم الحالات ، تحميل مخزن مؤقت كبير. يعمل تطبيق Heavy pixi على تنفيذ حوالي 400 استدعاءات فقط لكل إطار ،

بعد مواجهة مشاكل المستخدم مع الإحداثيات الكبيرة ، أفضل تخزين كل شيء بدقة مضاعفة حتى نقوم بتحميله.

أيضًا ، تدوين "a، b، c، d، tx، ty" أسهل في الكتابة والقراءة من "0،1،3،4،6،7". تستخدم أيضًا في العمود الفقري ، ولديها تحويلات معقدة للغاية علاوة على ذلك. إذا قمنا بالتبديل إلى المصفوفات ، فلن يكون من السهل التحقق من الكود الخاص بنا لاحقًا. بالنسبة لبعض الناس ، من الصعب تخيل عمليات المصفوفة ، لكني قرأتها بسهولة.

محدث. أعتقد أيضًا أن هذا سيساعدنا أكثر من مجرد تحويل المصفوفات: https://github.com/gameofbombs/gobi/blob/master/src/core/math/FlatTransform2d.ts ، هذا التحويل "مسطح" ، يحتوي على جميع الحقول المطلوبة لحساب المصفوفة.

تحديث 2. ولكن بالنسبة إلى التحويلات ثلاثية الأبعاد ، فإن Float32Array (16) أفضل ولن أتحدث ضدها.

صوتي يذهب إلى الذي يعطي أفضل أداء. آخر مرة قمت بفحصها باستخدام كائنات فوق المصفوفات كان أسرع. على الرغم من أنني لست متأكدًا بنسبة 100 ٪ مما إذا كان هذا لا يزال صحيحًا ، فمن المحتمل أن يكون قد تغير!

بالنسبة إلى 3d ، أفضل أسلوب gl-matrix ، خاصة عندما يتم تحميل الأشياء إلى وحدة معالجة الرسومات كثيرًا! مع Pixi ، هذا ليس هو الحال بشكل عام. يحدث معظم التلاعب في أرض js (على سبيل المثال ، آلة تجميع العفاريت).

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

هذا هو الاختبار الذي قمت به. الهدف من ذلك هو أبطأ من Float32Array، وكلاهما وسيلة أبطأ من صفيف العادي. ثم نحصل على الدقة المزدوجة وأسرع سرعة وحدة المعالجة المركزية، ويمكن تحميلها مباشرة.

تحرير: يبدو أن النتيجة Array كانت صدفة ، فأنا غير قادر على إعادة إنتاجها؟

صوتي يذهب إلى الذي يعطي أفضل أداء.
آخر مرة قمت بفحصها باستخدام كائنات فوق المصفوفات كان أسرع.

هذا شيء مشوق. يبدو من غير المنطقي أن الكائنات ستكون أسرع من المصفوفة الرقمية البحتة ، لأن جهاز vm الأساسي يجب أن يكون قادرًا على القيام بعدد من التحسينات ، مع العلم أنه يمكن تجريد دلالات الكائن إلى حد كبير. أشعر بالفضول إذا كان لديك أي أفكار _لماذا_ قد تكون الكائنات أسرع؟

النتائج ذات الصلة من شركاتي (i7 و Windows 10):

كروم 59:

Firefox 54.0.1 (32 بت):

مايكروسوفت إيدج 40.15063.0.0:

يبدو أن نتيجة الكروم التي حصلت عليها من Array كانت أسرع كانت حظًا ، لست متأكدًا مما كان عليه ولكن غير قادر على إعادة إنتاجه الآن. لقد كان حوالي 50 مليون عملية / ثانية ، ولكن كان 500 مليون عملية / ثانية في جولة واحدة قمت بها من قبل. عجيب...

في كلتا الحالتين ، يكون عضو Float32Array ثابتًا بنفس السرعة أو أسرع من الكائن في جميع المستعرضات. وهذا هو سبب تبديلها ، إنها نفس السرعة السابقة (أو أسرع) ولكننا نتجنب الآن نقل وتعبئة مصفوفة للتحميلات.

هل يمكنك فعل ذلك مع Float64 أيضًا من فضلك؟ :)

أهتم بجودة الكود أكثر من عملية مصفوفة واحدة أخرى لكل drawcall.

أيضا ، نحن لا نستخدم العكس كثيرا. updateTransform () هي مشكلتنا.

أهتم بجودة الكود أكثر من عملية مصفوفة واحدة أخرى لكل drawcall.

كيف يتم تحسين جودة رمز Float64Array؟ أفهم أننا نحصل على مزيد من الدقة ، لكنني لست متأكدًا من اتباع سبب أهمية ذلك نظرًا لأننا نقللنا إلى الدقة المفردة على أي حال.

أيضا ، نحن لا نستخدم العكس كثيرا. updateTransform () هي مشكلتنا.

هذا هو قياس القراءة / الكتابة لتخزين البيانات ، والعملية التي يتم إجراؤها على القيم الموجودة في البينية غير ذات صلة.

أهتم بجودة الكود أكثر من عملية مصفوفة واحدة أخرى لكل drawcall.

وأنا أتفق مع هذا أيضا. ضع في اعتبارك أن "التوحيد القياسي" على المصفوفات والنقاط والمتجهات المستندة إلى المصفوفة قد يكون في الواقع تحسينًا لجودة الكود أكثر من أداء واحد ... سأفكر في إعادة استخدام مكتبات مصفوفة js / vector الشائعة والمزيد من قابلية التشغيل البيني مع وحدات العرض الشائعة ليكون فوزًا كبيرًا بجودة الكود.

هذا هو قياس القراءة / الكتابة لتخزين البيانات ،
العملية المنجزة على القيم الموجودة في البينية غير ذات صلة.

أعتقد أن كلاكما على حق. هذا هو المعيار العام لتخزين البيانات قراءة / كتابة. لكن إيفان لديه نقطة جيدة حقًا. إذا كانت updateTransform() هي العملية الساحقة ، فسيكون من المقنع رؤية ذلك.

أنا قلق بشأن المعايير الجزئية بشكل عام ؛ مع مجموعات البيانات الثابتة هذه ، أتساءل عما إذا كنا سننتهي عن غير قصد بالاستفادة من تحسينات المترجم في جافا سكريبت vms في هذه الاختبارات. سيكون إجراء اختبارات العالم الحقيقي أكثر تنويرًا (على حساب زيادة العمل على الإعداد.)

وأنا أتفق مع هذا أيضا. ضع في اعتبارك أن "التوحيد القياسي" على المصفوفات والنقاط والمتجهات المستندة إلى المصفوفة قد يكون في الواقع تحسينًا لجودة الكود أكثر من أداء واحد ... سأفكر في إعادة استخدام مكتبات مصفوفة js / vector الشائعة والمزيد من قابلية التشغيل البيني مع وحدات العرض الشائعة ليكون فوزًا كبيرًا بجودة الكود.

أنا مع "(a، b)، (c، d)، (tx، ty)" مصفوفة مزدوجة الدقة ، مع التحويل إلى float32array للتحميل والمدعومة بـ "posX ، posY ، pivotX ، pivotY ، scaleX ، scaleY ، shearX ، shearY ، rotZ ". سأستخدمه في مفترقتي على أي حال ، لكنني أفضل عدم التعامل مع مصفوفات المصفوفة في الماستر بيكسي أيضًا. هذا هو المعيار الخاص بي.

أشك أيضًا في أنه من الممكن جعل الناس يستخدمون معيارًا أو اثنين من معايير vec في js.

كيف يتم تحسين جودة رمز Float64Array؟ أفهم أننا نحصل على مزيد من الدقة ، لكنني لست متأكدًا من اتباع سبب أهمية ذلك نظرًا لأننا نقللنا إلى الدقة المفردة على أي حال.

نقوم بضرب تحويل الكاميرا عن طريق تحويل الرموز (للتمرير) في updateTransform. تظهر النتيجة على الشاشة فقط إذا كانت صغيرة ، لذا فإن الأرقام صغيرة في النهاية ، ولكن يمكن أن يكون كل من موضع الكائن وموضع الكاميرا كبيرًا. حلول من جانب المستخدم:

1) يحسب كل شيء في جانبه. تتعامل PIXI فقط مع إحداثيات صغيرة نسبيًا.
2) قسّم العالم إلى أجزاء ذات روابط كبيرة ، فإن العفريت لها روابط صغيرة نسبيًا ، ولكن لن تعمل هذه الكاميرا مع البكسل الفرعي => تحتاج الكاميرا إلى أسلاك كبيرة وصغيرة أيضًا.

لا بأس في إجبار المستخدم على القيام بذلك من جانبه في حالة وجود مشروع كبير ، ولكن بالنسبة للمشروعات الصغيرة ، فهذا مجرد صداع إضافي.

أشك أيضًا في أنه من الممكن جعل الناس يستخدمون معيارًا أو اثنين من معايير vec في js.

لا أفهم ما تعنيه ، هل يمكنك التوضيح؟

لا أفهم ما تعنيه ، هل يمكنك التوضيح؟

لا أستطيع ، هذا كثير بالنسبة لي.

لدينا أشخاص لديهم خبرات مختلفة في كل من التحسينات منخفضة المستوى. وتراكيب اللغة ، DSL-s. نحن بحاجة إلى معيار يرضينا جميعًا على مستوى ما.

في العامين الماضيين ، صنعت شوكتين من pixi (لـ v3 و v4) مع تحويلات مختلفة ، أنا أتعامل مع "pixi-spine" التي لها تحويلها المتقدم الخاص بها وأنا أقوم بعمل شوكة ثالثة. من وجهة نظر "إيفان الماضي" ، المصفوفة هي الأفضل لأنها أبسط أشكال وهناك "مصفوفة gl".

أتفق مع ivanpopelyshev على أن الحفاظ على 64 بت أمر مهم. أحاول اكتشاف كيفية القيام بذلك ، بكفاءة ، دون إنشاء ونسخ مخازن مؤقتة لكل إطار.

ربما نقوم بتخزينه كـ Float64Array ، وعند تحميله انسخه في Float32Array. يتيح لنا ذلك على الأقل استخدام مصفوفة مكتوبة كدعم للتخزين والذي يجب أن يكون أسهل في النسخ إلى / من عامل الويب.

Float64Array بعد ذلك ، علي فقط أن أتذكر استخدام (0،1) ، (3،4) ، (6،7) كـ X ، Y ، ترجم

جميع اللاعبين المثيرين للاهتمام ، سأكون حريصًا على قياس حلنا المقترح في سيناريو بيكسي حقيقي - شيء مثل bunnymark.

تجربتي في هذا المجال هي أنه عندما قمت أنا و

كان ذلك قبل فترة وجيزة وأنا أفضل حقًا أن أكون مخطئًا هنا!
إذا كان فرق السرعة الآن ضئيلًا ، فأعتقد أن المسار المقترح أعلاه سيكون جيدًا.

سرعة Pixi: P لنتأكد من أننا نختبر قبل الالتزام الكامل بأي حل.

ما زلنا بحاجة إلى معيار Float64Array. هذا التنفيذ مقبول بالنسبة لي ، لكنني شخصياً سأستخدم المصفوفة القديمة في مفترقتي. لا تنس أيضًا إضافة خصائص للتوافق فقط.

شيء آخر: mreinstein ، أحد

هل هناك أي شيء يمكنني المساعدة في إعادة: هذا bunnymark المحدث؟ أنا سعيد للتبرع ببعض الوقت مع هذا.

سأكون مهتمًا جدًا بمتابعة أمور الأداء التي تحدث هنا. بغض النظر عن النتائج. إذا انتهى الأمر إلى أن العناصر المستندة إلى المصفوفة لا تزال أبطأ كثيرًا ، فأنا أشعر بالفضول حقًا بشأن _لماذا_ وراءها.

هناك شيء يجب ملاحظته: اختبار الأداء ... أصدر الإصدار v8 من الكروم مؤخرًا (في الإصدار 59) بعض التغييرات الدراماتيكية جدًا على الإصدار 8 المسمى turbofan. من المفترض أن لديها بعض التحسينات الهامة في الأداء.

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

قد يكون من المثير للاهتمام تشغيل bunnymark المحدث على إصدار قبل وجود turbofan مقابل الآن ، فقط من أجل التحقق منه.

GoodBoyDigital @ قمت بتحديث المقعد ليشمل Float64Array ، وهو أسرع في القراءة / الكتابة إلى المصفوفة من الكائن. إذا أصبح أبطأ في pixi ، فسيتم تغيير شيء آخر ، لأن القراءة / الكتابة إلى مخزن النسخ الاحتياطي Float64Array أسرع من الكائن.

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

فقط على Edge تتطابق / تتجاوز سرعة الكائن Float64Array ، وهي قريبة جدًا .

لقد اختبرت هذا في حسدي وحصلت على نتائج مماثلة ... ما هذا بحق الجحيم ؟! لماذا تكون قراءة / كتابة مصفوفة Float64 أسرع بكثير من عمليات مصفوفة Float32 المكافئة؟ الشيء الوحيد الذي يتبادر إلى الذهن هو أن تعويم 64 بت يتماشى مع حدود الكلمات؟ أنا في حيرة من أمري.

شكرا على العرض @ mreinstein ! إذا كان بإمكانك مساعدتنا في إجراء بعض اختبارات الأداء التي من شأنها أن تضع حداً للنقاش بأكمله بالحقائق القاسية الباردة!

أفضل ما يمكنك فعله هو fork pixi ثم استبدال المحولات بـ gl-matrix أو englercj matrix class. في هذه الحالة ، نحتاج فقط إلى جعل مجموعة الرموز تعمل أيضًا - وليس المحرك بأكمله!

ثم بمجرد أن يكون لدينا نسخة معدلة ، يمكننا اختبار الأداء هنا: https://pixijs.github.io/bunny-mark/
يمكننا العبث بأنواع المصفوفات المختلفة.

تضمين التغريدة من المشجع أن نرى هذه النتائج بالتأكيد. هل الإصدار v5 قريب من حالة يمكننا فيها إعطاء علامة الأرنب تدور؟

mreinstein مجرد حدس ، أعتقد أنه قد يتعلق بالتحويل من 64 بت -> 32 بت
كرقم في شبيبة هو 64 بت أليس كذلك؟

تضمين التغريدة يلجأ إلى صديقي السيدة. google ، لقد عثرت على هذا:

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

تبدو الإجابة الأعلى تقييمًا (حاليًا بـ 44 صوتًا) معقولة وذات صلة.

إذا كان بإمكانك مساعدتنا في بعض اختبارات الأداء

حسنًا ، سعيد للمساعدة في هذا. :)

أفضل شيء تفعله هو فورك بيكسي

GoodBoyDigitalenglercj ما هو أفضل فرع للتفرع منه في هذه المرحلة؟

ثم استبدل المحولات بفئة gl-matrix أو
في هذه الحالة ، نحتاج فقط إلى جعل مجموعة الرموز تعمل أيضًا - وليس المحرك بأكمله!

هل يمكنك توضيح هذا أكثر من ذلك بقليل؟ لا أرغب في تحويل المحرك بالكامل إلى gl-matrix فقط لتشغيل معيار الأداء ... لا أرى أي عناصر دفعة من الرموز المتحركة في https://github.com/pixijs/bunny-mark يبدو أن هناك PIXI.Container كعنصر جذر تضاف إليه الأرانب. هل تقول أنه يجب أن أبدأ بـ pixi.container ، pixi.sprite وأعمل للخلف من هناك إلى أعلى شجرة التبعية للعثور على جميع الأماكن التي تحتاج فيها أشياء التحويل إلى الاستبدال؟ لا أقول إنني لا أوافق ، فقط أريد التأكد من أنني حصلت على الإستراتيجية الصحيحة لتقليل العمل غير الضروري.

يحتوي التحويل على عمليتين مصفوفتين في الداخل:

1. التكوين من الموضع ، والمحور ، والمقياس ، والدوران - لا يمكن تحسينه.
2. الضرب بالمصفوفة الأصلية - يمكن تحسينه.

أقترح إنشاء فئة مصفوفة باستخدام الدعائم القديمة "a ، b ، c ، d ، tx ، ty" مدعومة بـ Float64Array ، وإعادة كتابة updateTransform. أيضًا ، صنع mreinstein أشياء كافية ليكون في الصميم ، أقترح أن نضيفه ، حتى يتمكن من الوصول إلى الفروع وبناء مزرعة.

حتى يتمكن من الوصول إلى الفروع وبناء المزرعة.

كل شخص لديه حق الوصول إلى ذلك ، fork + PR يفعل كل ذلك.

أشعر بالفضول لمعرفة أنواع النتائج التي يحصل عليها الأشخاص في علامة الأرنب .. عندما أحاول العديد من الفروع (dev ، الإصدار ، وغيرها) من الكروم باستخدام الأرانب الافتراضية التي يبلغ عددها 100 ألف ، أحصل على 10-16 إطارًا في الثانية باستمرار. إجراء تحليل للأداء على الكود الذي يعمل بأكثر من 8.75 ثانية:

يتم قضاء معظم الوقت تقريبًا في مكالمات جافا سكريبت.

من هذا الوقت الذي يقضيه في جافا سكريبت ، يتم إنفاق نصيب الأسد من الوقت في Sprite.calculateVertices() . أربعة أضعاف ما تم إنفاقه في TransformStatic.updateTransform()

في Firefox أحصل على ضعف معدل الإطارات ، لكن تقسيم الوقت المستغرق مماثل ؛ يستغرق calculateVertices() الجزء الأكبر من الوقت في كلا المستعرضين. هل هذا متوقع؟ هل تحصل على نتائج مماثلة في جولات bunnymark الخاصة بك؟

هذا متوقع للأرانب. ويتم تنفيذ عمليات المصفوفة التي نتحدث عنها في مكانين: upateTransform () من أجل الضرب والشطف () مرة واحدة لكل مكالمة. لا يهم على نطاق واسع.

انا مرتبك. :( كيف يمكنني معرفة أداء هذا المعيار؟ كان لدي انطباع بأنه يعتمد في الغالب على معدل إطارات في الثانية تم تحقيقه. إذا كان هذا صحيحًا ، فإن معدل عرض الإطارات لدي _ بشدة _ يتم اختناقه بواسطة حسابات الرؤوس. بالنظر إلى الرسم التخطيطي الأول الذي قمت بلصقه أعلاه ، يعتبر العرض جزءًا صغيرًا من إجمالي وقت الإطار. تتسبب تحديثات الرأس والتحويل في تجاوز إجمالي وقت الإطار.

إذا كان هذا خطأ ، ولم يكن معدل الإطارات في الثانية مقياسًا لمدى أداء بنية pixi الخاصة بي ، فما المعايير التي أستخدمها لقياس تصميم معين؟

يمكن خنقه إما على وحدة المعالجة المركزية إما على جانب وحدة معالجة الرسومات (لا يظهر) ،

إذا كان لديك FPS أقل بكثير من 60 ولكن "الخمول" كبير - وحدة معالجة الرسومات الخاصة به.

إذا كان الخمول صغيرًا ، فإن وحدة المعالجة المركزية الخاصة به.

حسابالأصابع لديها عملية مصفوفة بداخلها - فقط ضرب أربع زوايا بالمصفوفة.

مجرد فكرة صغيرة عن TS fork: أضف تحويلًا يتضمن خصائص لأنواع المصفوفات. من العار أنه لا يوجد هذا النوع من التحولات لـ TS حتى الآن :(

أعتقد أنه يمكن القيام به لبابل أيضًا إذا وجدنا طريقة لتوضيح متغيرات المصفوفة.

لا أستطيع أن أفهم ما يجري بعد الآن.

شيء يجب مراعاته: الهدف من هذا المعيار في المقام الأول هو معرفة ما إذا كان استخدام الكائنات مقابل gl-matrix سيكون بمثابة نجاح كبير في الأداء ، كما كان يعتقد. بغض النظر عن الاختلافات في نتائجنا المعيارية ، يبدو أننا نظهر باستمرار أن أداء الكائن ليس أسوأ من معظم حالات المصفوفة.

أريد أيضًا تجنب استخلاص استنتاجات الأداء حول pixi بشكل عام هنا لأنني حددت علامة الأرنب. في Chrome ، يتم إنفاق أكثر من 50٪ من إجمالي وقت البرنامج في Sprite.calculateVertices() (40٪ ish) ، متبوعًا بـ TransformStatic.updateTransform() (11٪ ish) يبدو أن Firefox يعمل بسرعة مضاعفة ، لكن النسبة من الوقت المنقضي في هاتين الوظيفتين لا يزال ثابتًا.

أريد أن أتجنب الابتعاد عن الموضوع كثيرًا ، لكنني سأقول أنه عند القيام بتنميط bunnymark هذا ، بدأت أعتقد أن استخدامنا لـ es5 getters / محددات قد يكون له علاقة بانخفاض الأداء في الكروم: https: //jsperf.com/es5-getters-setters-versus-getter-setter-methods/10

هل يتسكع أي منكم على سلاك هنا؟ أعتقد أنه سيكون من الأسهل الدردشة في الوقت شبه الحقيقي بدلاً من تمرير الرسائل هنا.

ماذا ترسل بريدا إلكترونيا إلى mreinstein ؟ سوف أدعوكم إلى Slack 👍

بناءً على ما يقوله englercj ، يبدو أننا لا نفعل ذلك. إغلاق.

مجرد تحديث صغير: لدي مصفوفة 3x3 بدلاً من 3x2 في https://github.com/pixijs/pixi-project/blob/master/src/Matrix2d.ts ، بناءً على Float64Array.

تم قفل سلسلة الرسائل هذه تلقائيًا نظرًا لعدم وجود أي نشاط حديث بعد إغلاقه. الرجاء فتح قضية جديدة للأخطاء ذات الصلة.