I have a webgl page running in chrome.
Every now and then chrome will report the following error.
[.WebGLRenderingContext]GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to render with no buffer attached to enabled attribute 1
I've tried to debug where the error is occurring but I cannot. I can reliably cause it to occur, but when I debug the error is reported on seemingly random lines. I suspect this is because of the asynchronous nature of gpu rendering.
Is there a good way to debug this?
You can use a debug wrapper to wrap the WebGL context and call gl.getError after every WebGL function.
There is an example of one available on the official WebGL Wiki.
Per default WebGL doesn't tell you much about it, you have to query all the information you need yourself. Once you know how to do that, those errors will tell you all you need to debug it. The getter for your case would be
var attribLocation = 1;
gl.getVertexAttrib ( attribLocation, gl.VERTEX_ATTRIB_ARRAY_BUFFER_BINDING );
Which, if you query it before your draw call, will probably return null, which means you're not calling vertexAttribPointer correctly when setting up or switching buffers.
So you go to the point in your code where you set the pointers and enable the arrays and confirm that the location you just enabled with enableVertexAttribArray returns also returns null if you query the buffer at this point. Now you know if you messed up with the pointer. You know you fixed it, when the query returns the correct WebGLBuffer Object.
There are getters for all the states (WebGL is mostly about managing state), they are a bit tricky to use, but using them will greatly help you understand everything going on all the time, when you need or don't need to make calls in order to update that state and where you made mistakes.
You can look the getters and the arguments they take up in the spec
SpectorJS is a tool aimed at WebGl developers wanting to know what happens in their context. It enables capturing of all the available information from a frame. You will be able to look at your entire commands list with their associated visual states and context information.
https://github.com/BabylonJS/Spector.js
Related
I have been using tfjs qna model, repo here for doing some question answering tasks. I wanted to access the internal model states for this model, specifically attention matrices for the intermediate layers that I want to display.
My constraints are that I cannot use python or ajax, this needs to work in a browser environment (thus using something like bertviz is not possible).
I found the part that calls the tf model which is linked here.
It does a model.execute(...) on the question, passage to get a series of start and end logits. The aforementioned model has an executor key that looks as follows:
I see in this a keepTensorForDebug argument that I tried turning to true, but that seems to just retain the output logits related to the question-answering only, and not the intermediate attention tensors of the mobilebert model that it is using. What I essentially need access to is a way to stop the execute function from disposing the intermediate tensors, but I have not been able to find a way of doing this. I did find the source code for the executor function, but was unable to understand how to change it to retain the tensors that it is disposing.
Please let me know and I can provide any additional details. Any help is appreciated. Thank you.
In my application I need to know when a user switches to show his screen instead of camera, both the local user and for other users. When I change to showing the user's screen, MesiboGroupcall_OnVideoSourceChanged is not called. The only listeners that are called is MesiboGroupcall_OnVideo and MesiboGroupcall_OnAudio for the local participant, and no listeners for remote participants.
Inspecting the participant through the console shows that the listener have indeed been set to be my desired function,
MesiboGroupcall_OnVideoSourceChanged: (newVideoSource, oldVideoSource) => {
console.log("MesiboGroupcall_onVideoSourceChanged: newVideoSource:", newVideoSource, "- oldVideoSource:", oldVideoSource);
}
but it won't run. Do anyone have any tips on getting this to work?
From what I can decipher reading mesibo.js, MesiboGroupCall_OnVideoSourceChanged is the only listener that is referenced only twice, when it is declared and when it is set in the call method. It seems like it isn't called elsewhere, for instance I would expect it to be called in to methods that change the video source like .setVideoSource(). I also find no reference to MesiboGroupcall_OnVideoSourceChanged in the source code for the live demo web application, which leads me to suspect that it might not be implemented yet or work correctly. If any mesibo devs read this, maybe they can clarify.
It would also be useful to get information back locally when the user allows or disallows the screensharing, are there any way of doing this with mesibo? I see other video conference providers do this through promises, but I have a hard time seeing if anything similar is available for mesibo, without having more documentation on the mesibo interface.
I thought maybe I can listen for it through the DOM, but haven't looked into doing that yet. If anyone has any experience or thoughts on this, that would also be great.
I'm currently debugging an Angular (JS) based app. I have some speed issue on runtime (client side) and want to analyze why.
I use the Devtool profiler from Chrome. I can see that some Events (i.e. keypress, blur) took a lot of time (see screenshot below).
Now I would like to go deeper and know which source code contains these event listeners and cause my application to slow down like this.
For information, the app is very slow when I write text in input, and when I focus/blur from my input; I know that some watchers could cause the slow down, but I'm not sure.
Hope deeper profiler analysis could help me !
--- Edit 25 feb 2020 ---
I think my problem is linked to digest cycle (apply/digest, etc).
I found this plugin : digest-hud. After several tries, it seems that a binding (which is used in a lot of components) called "source" is taking all digest resource :
Digest-hud was really helpful. I cannot find a way to know exactly how to find ha function initial calls on callstack. Like Kresimir Pendic said, probably a map issue.
But I found a lot of binding/watcher with source and one of them was called every single event of focus/blur/tipping. So I removed it, find an other way to signal changes within input and it works.
So don't hesitate to check with Digest-hud (disclaimer, I'm not releated in any way with Digest-hud developer(s)) if you have some performance issue with your AngularJS app, it'll give you some hints to solve the problem.
We have built a small script and a database, based on PouchDB in order to display all the products of one of our clients in a so called "product tree".
You can find the product tree here: http://www.bodyrevitaliser.nl/nl/service/product-tree/
As you can see the tree is loading properly only in Chrome. If you check the console in safari and Firefox the DB seems to be loaded as well but something seems to be blocking the tree itself to be loaded.
What are you thoughts? Any ideas what might be causing this and solutions.
The problem with your code is that your usage of promises is not correct. I strongly recommend you read this blog post: We have a problem with promises. I know it's long, but it's worthwhile to read the whole thing.
In particular, read the section called "WTF, how do I use forEach() with promises?", because that is exactly the mistake that you're making. You are doing a bunch of insertions inside of a $.each, and then you are immeditely doing an allDocs() inside the same function. So you have zero guarantees that any documents have actually been inserted into PouchDB by the time you try to read from PouchDB. Perhaps it will, perhaps it won't, but it all depends on subtle timing differences between different browsers, so you can't count on it.
I'm using the setTimeout() function in javascript to allow a popup that says "loading" to be shown while I'm parsing some xml data. I found that at small enough delay values (below 10ms) it doesn't have time to show it before the browser freezes for a moment to do the actual work.
At 50ms, it has plenty of time, but I don't know how well this will translate to other systems. Is there some sort of "rule of thumb" that would dictate the amount of delay necessary to ensure a visual update without causing unnecessary delay?
Obviously, it'll depend on the machine on which the code is running etc., but I just wanted to know if there was anything out there that would give a little more insight than my guesswork.
The basic code structure is:
showLoadPopup();
var t = setTimeout(function()
{
parseXML(); // real work
hideLoadPopup();
}, delayTime);
Thanks!
UPDATE:
Turns out that parsing XML is not something that Web Workers can usually do since they don't have access to the DOM or the document etc. So, in order to accomplish this, I actually found a different article here on Stack Overflow about parsing XML inside a Web Worker. Check out the page here.
By serializing my XML object into a string, I can then pass it into the Web Worker through a message post, and then, using the JavaScript-only XML parser that I found in the aforementioned link, turn it back into an XML object within the Web Worker, do the parsing needed, and then pass back the desired text as a string without making the browser hang at all.
Ideally you would not ever have to parse something on the client side that actually causes the browser to hang. I would look into moving this to an ajax request that pulls part of the parsed xml (child nodes as JSON), or look at using Web Workers or a client side asynchronous option.
There appears to be no "rule-of-thumb" for this question simply because it was not the best solution for the problem. Using alternative methods to do the real meat of the work was the real solution, not using a setTimeout() call to allow for visual update to the page.
Given options were:
HTML 5's new Web Worker option (alternative information)
Using an AJAX request
Thanks for the advice, all.