Pixi.js: बहुत अधिक सक्रिय WebGL प्रसंग

@andrevenancio
मैं पिक्सी देखने में कोई विशेषज्ञ नहीं हूं क्योंकि मैं इसे केवल सोमवार या मंगलवार से उपयोग कर रहा हूं, हालांकि। यदि आपके पास कई प्रयोगों ( इस तरह ) के कारण एक से अधिक रेंडरर्स और कैनवस हैं, तो एक समय में केवल एक को एक्सेस करने की आवश्यकता है, मेरे पास एक वैश्विक रेंडरर या कोई अन्य होगा, और प्रयोगों को एक सरणी में रखेगा। फिर जब आपको इसे प्रदर्शित करने की आवश्यकता हो, तो बस प्रत्येक प्रयोग के चरण को रेंडरर में पास करें।

var renderer = PIXI.autoDetectRenderer({blah});
var experiments = [];
experiments.push(experiment1);
experiments.push(experiment2);
experiments.push(experiment3);

var currentExperiment = $('#experminetSelector').val();
renderer.render(experiments[currentExperiment]);

इस तरह आप केवल एक बार रेंडरर बना रहे हैं और बस इसे प्रत्येक प्रयोग से स्टेज पास कर रहे हैं। हालांकि यह केवल तभी काम करता है जब आप बहुत सारे अलग-अलग प्रयोग पृष्ठ रखने के बजाय केवल एक पृष्ठ प्रस्तुत करने का प्रयास कर रहे हों और उस पर सभी प्रयोग कर रहे हों।

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

एकल रेंडरर और एकाधिक दृश्य होना ठीक होना चाहिए। 1 रेंडरर === 1 कैनवास तत्व।

हे दोस्तों, आपकी प्रतिक्रिया के लिए धन्यवाद। @samuraiseoul आप जो सुझाव दे रहे हैं वह बिल्कुल भी मूर्खतापूर्ण नहीं है, और इस तरह मैं आम तौर पर एक ढांचे में कई प्रयोग करने के लिए आगे बढ़ता हूं ... हालांकि, मुझे एक और समाधान करने की आवश्यकता होगी क्योंकि प्रयोग pixi.js का उपयोग करके किए जा सकते हैं। threejs या सादे WebGL। इसके अलावा, उसके ऊपर, प्रतिक्रिया संरचना में पहले से परिभाषित संक्रमणों के प्रकार के कारण, एक बिंदु पर आप पुराने प्रयोग को देखेंगे, और एक ही समय में नया प्रयोग, एक साथ प्रतिपादन, इसलिए एक रेंडरर का विचार जीता काम नहीं ....

इसके अलावा.... यह समस्या का समाधान है, स्वयं समाधान नहीं... यदि .destroy() विधि वास्तव में webgl संदर्भ के संदर्भ को नष्ट नहीं करती है... तो इसका क्या मतलब है? :(

यो दोस्त! पूरी तरह से सहमत हैं कि नष्ट कार्य वास्तव में ऐसा नहीं कर रहा है जो संदर्भों को नष्ट नहीं किया जा रहा है :)

मैं भटकता हूँ, क्या आप autodetectRenderer का उपयोग कर रहे हैं? यह हो सकता है कि ब्राउज़र वेबजीएल सक्षम है या नहीं यह पता लगाने के लिए हम जो परीक्षण संदर्भ बनाते हैं, उसे नष्ट नहीं किया जा रहा है।

कुछ अतिरिक्त जानकारी: आप वेबलॉग संदर्भ को नष्ट नहीं कर सकते हैं, वे कचरा एकत्र किए जाते हैं (जब तक कि कुछ नहीं बदला है?)

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

क्या देव उपकरण इस तरह के संदर्भों के आसपास लीक का संकेत देते हैं? शायद यह मदद कर सकता है? लगता है जैसे कुछ संदर्भ को चारों ओर रख रहा है .. शायद एक जेएस संदर्भ को संदर्भित करता है या एक जेएस अंतर्निहित कैनवास को संदर्भित करता है?

यही कारण है कि मैं अभी भी iframes से प्यार करता हूँ चाहे कुछ भी हो।

@GoodBoyDigital मैं इस तरह autodetectRenderer का उपयोग कर रहा हूँ

<strong i="9">@renderer</strong> = new PIXI.autoDetectRenderer canvas.width, canvas.height, { view: canvas, antialias: false, backgroundColor: 0xffffff }

मैं इसे अभी के लिए पार्क कर रहा हूं, आप लोगों को बता दूंगा कि जब मुझे एक मिला तो समाधान क्या है .. मैं बस सोच रहा था कि उस संदर्भ को खोने के लिए, शायद कचरा संग्रह को इसे साफ करने के लिए मजबूर किया जाएगा .. लेकिन इसके बारे में निश्चित नहीं है :)

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

कोइ प्रगति?

स्पष्ट होने के लिए, मैं फेजर का उपयोग कर रहा हूं, लेकिन ऐसा लगता है कि यह पिक्सी के रेंडरर को कॉल कर रहा है। विधि को नष्ट करें।

अभी तक कोई भाग्य नहीं। यदि आप या तो एक वैश्विक रेंडरर का उपयोग कर सकते हैं और आप इसमें अलग-अलग दृश्य प्रस्तुत करते हैं, या, केवल एक आईफ्रेम के माध्यम से सामग्री लोड करते हैं और जो कुछ भी लटक रहा है उसका ठीक से निपटान करता है।

अरे झाँक, हाँ यह वास्तव में थोड़ा मुश्किल है। जहाँ तक मैं देख सकता हूँ हम एक संदर्भ को नष्ट करने के लिए हर संभव प्रयास करते हैं। तो सभी बनावट/कार्यक्रम arraybuffers ect नष्ट हो जाते हैं। हम क्या कर सकते हैं शायद संदर्भों को एक बार नष्ट कर दिया जाए ताकि हम हर बार एक नया बनाने के बजाय उनका पुन: उपयोग कर सकें?

अरे @GoodBoyDigital मेरे मामले में मेरे पास एक एनीमेशन था/बाहर इसलिए मुझे हमेशा 2 संदर्भों की आवश्यकता होगी ... यह प्रतिक्रिया के साथ एकीकृत करने और इसे पूर्ण पिक्सी नहीं बनाने में समस्या है ... प्रति कहते हैं .. मुझे लगता है कि यह ब्राउज़र की तरह संदर्भों का प्रबंधन करता है ... यह भी नहीं पता कि यह तीन से हैक काम करता है। जेएस काम करता है ... शायद इसे अपने वी 4 पर जाने दें और पिक्सी के साथ 16+ टैब खोलने का प्रयास करें https://github.com/mrdoob/three.js/blob/master/src/renderers/WebGLRenderer.js#L289

अन्यथा कोई चिंता नहीं दोस्त, मैंने पहले ही अपने ऐप का आर्किटेक्चर बदल दिया है ... iframe FTW :)

अच्छी बात है यार! मैं निश्चित रूप से three.js ट्रिक को भी जोड़ने पर ध्यान दूंगा।

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

दूसरे शब्दों में, उपयोगकर्ता कोड लिख रहा है। यह पूर्व लिखित नहीं है।

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

यह संदर्भ हानि को बाध्य करने के लिए इस तकनीक का उपयोग करता है:

gl.getExtension('WEBGL_lose_context').loseContext();

यहां एक पूर्ण उदाहरण दिया गया है:

var document = require('global/document');
var PIXI = require('pixi.js');

// I want to keep this canvas / renderer around. For example, this might be a bottom layer PIXI / React map overlay.
var canvas1 = document.createElement('canvas');
document.body.appendChild(canvas1);
createRenderer(0xff0000, canvas1);

function createRenderer(color, canvas) {
  canvas = canvas || document.createElement('canvas');
  var renderer = new PIXI.WebGLRenderer(800, 600, {view: canvas});
  var stage = new PIXI.Container();
  var graphics = new PIXI.Graphics();
  graphics.beginFill(color, 0.5);
  graphics.drawCircle(0, 0, 200);
  graphics.endFill();
  stage.addChild(graphics);
  renderer.render(stage);
  return {renderer: renderer, stage: stage, graphics: graphics};
}

// Simulate frequent adding / removing of lots of PIXI / React map overlays on top.
for (var i = 0; i < 16; i++) {
  var canvas = document.createElement('canvas');
  document.body.appendChild(canvas);
  var scene = createRenderer(0x00ff00, canvas);
  // Uncomment to see that the original canvas isn't removed.
  /* scene.renderer.currentRenderTarget.gl
      .getExtension('WEBGL_lose_context').loseContext(); */
  scene.renderer.destroy();
  scene.stage.removeChild(scene.graphics);
  document.body.removeChild(canvas);
}

हो सकता है कि PIXI को इसे अपनी "नष्ट" विधि में जोड़ना चाहिए?

यह समझ में आता है अगर हम संदर्भ के मालिक हैं, जो मुझे लगता है कि अभी हम मानते हैं कि हम करते हैं (v3)।

फंक्शन में हैWebGLSupported() (source/core/utils/index.js) रिप्लेस
return !!(gl && gl.getContextAttributes().stencil);

साथ
var success = !!(gl && gl.getContextAttributes().stencil); gl.getExtension('WEBGL_lose_context').loseContext(); gl = undefined; return success;

मेरे लिए समस्या तय की। यह Google क्रोम में सबसे प्रमुख था - फ़ायरफ़ॉक्स ने किसी भी तरह से काम किया। जैसा कि मैं एक वेबजीएल नोब का थोड़ा सा हूं, मैं इस दृष्टिकोण पर टिप्पणी के लिए वास्तव में आभारी रहूंगा।

अच्छी कॉल की जाँच करते समय जबरन संदर्भ खो जाना, यह एक अच्छा विचार है क्योंकि हम जानते हैं (१००%) कि हम उस संदर्भ के स्वामी हैं।

क्या यह विलय हो गया? हमें एक ही समस्या हो रही है।

पिंग @englercj मुझे लगता है कि इसे अब बंद किया जा सकता है

gl.getExtension('WEBGL_lose_context').loseContext() चेतावनी को दबा सकता है लेकिन कल्पना का कहना है कि यह केवल संदर्भ खोने का अनुकरण करता है, जब तक कि WEBGL_lose_context.restoreContext() कहा जाता है - जो संदर्भ को केवल तभी पुनर्स्थापित कर सकता है जब यह वास्तव में पहली जगह में खो गया नहीं था।

यह उपयोगी हो सकता है: loss_context() केवल एक अनुकरण है (कल्पना के अनुसार) लेकिन इस धागे में ( सार्वजनिक वेबजीएल: WEBGL_lose_context हम सीखते हैं (मोज़िला डेवलपर जेफ गिल्बर्ट से) कि फ़ायरफ़ॉक्स में loseContext() लिए एक उपशब्द है " इस संदर्भ को जारी करें और इसकेसंसाधन" ।

समस्या यह है कि अन्य ब्राउज़र इसे अलग तरीके से संभालते हैं। एक Google डेवलपर (केन रसेल) की ओर से अनुशंसा की गई टिप्पणियां हैं:

मुझे यह स्वीकार करना होगा कि मैंने इनमें से किसी के साथ प्रयोग नहीं किया है, लेकिन ऐसा लगता है कि कोई भी समाधान ब्राउज़र विशिष्ट होने जा रहा है।

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

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

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

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

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

ऐसा लगता है कि यह किसी एक पेज के ऐप में PIXI का उपयोग करने में एक समस्या होगी।

आपके PIXI.Application/PIXI.WebGLRenderer/PIXI.CanvasRenderer के इंस्टेंस को सेव करने से आपके कैनवास एलिमेंट का इंस्टेंस भी सेव हो जाएगा। उदाहरण के लिए, PIXI.Application में, आप view संपत्ति प्राप्त कर सकते हैं जो HTMLCanvasElement है। आप इस कैनवास तत्व को सम्मिलित कर सकते हैं और इसे अपने AngularJS/React ऐप से हटा सकते हैं। PIXI में आप रेंडरर को बता सकते हैं कि कौन सा कैनवास तत्व इसे एक विकल्प के रूप में उपयोग करना है, हालांकि, आपको इसका उपयोग नहीं करना चाहिए। इसके बजाय, PIXI को आंतरिक रूप से अपना स्वयं का कैनवास तत्व बनाने की अनुमति दें और बस कुछ DOM कंटेनर में चाइल्ड को संलग्न करें।

<div id="pixi-container"></div>

// maintain the reference to this Application even as your SPA view gets destroyed
const app = new PIXI.Application();

// Insert in the DOM or whatever the equivalent is in Angular
document.querySelector("#pixi-container").appendChild(app.view);

ठीक है, धन्यवाद, मैं इसे आज़मा दूंगा। वास्तव में बिल्कुल भी बुरा नहीं लगता।

ठीक है, इसे नष्ट करने के बजाय दृश्य को अलग करने और दोबारा जोड़ने से मेरी समस्या हल हो गई, मदद लोगों के लिए धन्यवाद।

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