Wild time differences measured in Node.js program - javascript

I've noticed an odd behavior in a program I am working on. While it's probably my fault, I wanted to check if someone faced this before.
Both with console.time and performance-now my code has highly variable run time. I can't exactly paste it here because it's work related, but the workflow is:
start timer
load image via jimp
when image is loaded, scale image times 2
scan the image, transform pixels in zeroes and ones and put it into an array
log time
Some discrepancy is sure to be expected, but the results are so different I'm wondering what I did wrong. Average time is short, but the outliers are pretty... well, you can see on the image below.

Related

JavaScript Canvas requestAnimationFrame freezing tab

I've been working on a 2D game in JavaScript using the canvas, and I found that requestAnimationFrame seems to make the game much smoother, which is great. However, the game has been freezing at random times ever since. The tab becomes stuck, and the game doesn't throw any errors, so I'm kind of at a loss. I have tried many things to manually debug it, such as constantly updating a LocalStorage variable, just displaying in the console, etc. Nothing is really giving me any results.
I can say that my experiments lead me to believe that there may be some strange asynchronous behavior associated with requestAnimationFrame; namely, I have noticed that if I change the size of something via socket.on, such as an array, and the game happens to be running a for-loop on that array, it sometimes crashes mid for-loop saying that the thing I'm referencing is undefined, even though I check for that right before the for-loop. Moreover, I noticed that when requestAnimationFrame calls code, such as my Game.update() function, sometimes the "this" object isn't properly referencing the object I'm in. ie., in Game.update(), this.draw_something() would throw an error. I have fixed those issues I believe, but I'm wondering if anyone has any insight into the overall nature of requestAnimationFrame.
The last thing I want to mention is that when the tab freezes, the memory begins to sky-rocket. It quickly goes from a few hundred MBs (from pre-loaded gfx, etc) to around 2 gigs, and continually increases.
I hope someone has some good feedback - and thanks in advance.

Possible sources of an asynchronous bug in a WebGLRenderingContext?

I have an animation loop running in which I'm getting an error that reads...
GL ERROR :GL_INVALID_OPERATION : glDrawElements: Source and destination textures of the draw are the same.
This error pops up after between 2 and 3 animation frame requests, depending on whether I've refreshed or hard refreshed the screen - and even then the timing of the error is not consistent. A hard refresh may occasionally delay the error from showing up until after 3 frame requests, but most of the time for both a refresh and hard refresh the error shows up after 2 frame requests. Based on those observations, the problem seems to be in an asynchronous component. I also have a simpler toy version of this loop running without any errors. I've been simplifying the buggy program more and more (it's now just displaying a non-moving cube) and still can't find the source of the problem.
The program is decently complex, so it's hard to determine what code to show here, so instead I'm hoping for an answer that may teach me a little about approaching a problem like this generally, so I can apply it whenever I hit similar situations: My question is, what are the top candidate areas in a program for a problem like this? Knowing that, I can focus my efforts.
I hope this makes sense - let me know if you need further clarification. Thanks!
Update:
This seems quite basic, but I will add that when I put no objects in the scene (cubes, axis helpers, etc.) and leave everything else the same, the error goes away.
Also, I'm wondering if this sort of error can occur because of a lost context? Like so.
You probably need to post your code but just guessing...
First off the error is exactly what it says it is. You have a texture attached to the current framebuffer. That same texture is also assigned to some texture unit.
Why that happens intermittently I can only guess. If you're loading textures from images or even from dataURLs they load async. Being in the cache or if you're testing locally they'll load quickly. So, my guess would be you're not correctly setting your texture units every frame (calling gl.activeTexture and gl.bindTexture for each texture unit used by your shaders). When your image is finally downloaded async you call gl.bindTexture to upload the texture. That ends up assigning a texture to whatever the current active texture unit is and messes up your setup.

Take a huge screenshot of a webpage (over 13500x13500px size)

I have about 3000 images of about 256x256px size (but some are 50x256 and some are 256x100 or so) which I wish to merge into one big picture. The images are shown in a webpage, thus the easiest way would be to take a screenshot of the said webpage. The webpage's image is of about 13500x13500px ! On theory, I could download all of the images and merge them together (with like bitmap() or CopyImage() or something like that but I really wish to go with an easier solution). Oh and this 3000->1 is one of about 120 in total cases that I have to do.
I've tried several methods, none of which worked out properly:
phantomJS (the .exe crashes after a while)
CutyCaps (the .exe crashes after a while)
Firefox's "screenshot --fullpage bla.png" (crashes with exception,
known issue with huge pages since the dawn of firefox)
SeleniumSDK (FirefoxDriver, crashes after a while)
html2canvas (crashes or just won't start)
basic javascript and canvas work (failed miserably)
A dozen of the top extensions for firefox (takes forever, then
crashes or produces a broken image)
A dozen of the top extensions for Chrome (takes forever, then
crashes or produces a broken image)
The only service that ever worked out perfectly was http://web-capture.net but I really wish to have an offline/local method to generate the image, due to the amount of times that I'd have to visit any 3th party website.
If anyone could point me to any better offline service or a solution, I would be very grateful. Any working code snippets (preferably in either php/javascript/java/selenium/c#) are highly appreciated.
More on the project itself:
The source data is a photograph of a cell, shown with LeafletJS (similar to GoogleMaps). I made up a web scraper of sort, which pulls all the data from the viewer page and shows them as a one huge picture, formed out of thousands of other smaller images (with sometimes different sizes). The Histology course has about 120 different images that I'd wish to have locally stored, hence this whole exercise. Also, to make stuff interesting, every image is of different size, but lets say that it has about 55-60 columns and 50-80 rows of small 256x256 images, forming the big picture.
Here is a preview of what I'm talking about:
http://89.215.196.209/Anatomy%20%28Histology%29%20data%20parser.htm
Sorry for the long post, have a cookie.
I actually just installed and checked out the 64x ver of wkhtmltoimage and it works out perfectly.

Chrome canvas becomes blank after waking up from standby mode

Our application downloads about 15meg of images and displays them in a html canvas. We are doing a bit of stress testing and have found that after we have about 10 tabs open if we put the computer in sleep mode, when it comes back the canvas is blank - it just shows plain white (this doesn't happen every time, but very frequently).
We hold the images in JavaScript Image objects, and I have inspected the memory in those and they still appear to be valid. I've tried to use the Chrome memory analysis by taking a snap shot before and after the error occurs, in some cases less memory is being used, in other cases more, so that didn't seem to tell me much.
I am curious if anyone has seen this before, and even if not, does anyone have pointers about debugging something similar. It would be perfectly sufficient if there was a way for us to determine if the error had occurred so we could trigger a reload of the images, but I'm afraid until I figure out what is causing it, I won't even know what to try and inspect.
#rtpg - the draw loop was continuing to run, but it would not display anything
For some reason the canvas would no longer update. I was unable to determine when the problem occurred but did figure out how to get the canvas to start displaying the images again. It was required that I resize the canvas (I change the width by one pixel) and then redraw (it's embarrassingly hackish). I current have it set to run every 30 seconds through setTimeout, but will probably change to window.onfocus once I can verify that gets called when coming out of sleep mode.
There are major canvas issues in Chrome 29.
You may want to check out and star this issue:
https://code.google.com/p/chromium/issues/detail?id=280153
(This stress test is failing too and may be related)

How much of an effect can CPU have on JavaScript setInterval

I wrote a small jquery plugin that basically converts all words in an html element to spans, makes them invisible and then animates them into view. I made it so that you can define the time that it's supposed to take to load the whole element, and based on tests the math seems to be right, but in practice it takes quite a bit longer.
See jsfiddle: http://jsfiddle.net/A2DNN/
Note the variables "per" and "ms", this basically tells it to process "per" number of words every "ms" milliseconds.
In the log you'll see it'll process 1 word ever 1 ms, which should result in a MUCH faster loading time.
So I'm just wondering, is it possible that the CPU is forming a bottleneck here? In that JS is fading items into view, which is handled by the CPU, which isn't very fast at graphical processing.
It sounds almost silly to ask, I'd expect these days a CPU would laugh at a small bit of work load like this.
It is due to a minimum timeout forced by the browser's JavaScript implementation. You can't have a 1ms timeout, it is slightly more than that. There has already been a discussion about that here.

Categories

Resources