I have a Raphael javascript program, where I have several (dozens, hundreds, whatever) circles written to the page, like so:
evo_sprite = paper.circle(evo.x, evo.y, this.evo_size);
Each circle has a limited amount of time I want it displayed, after which I want it destroyed so it doesn't slow stuff down.
When I do:
evo_sprite.hide();
I have no problems, but I know the sprite is still there, and thus still taking up memory.
So I tried:
evo_sprite.remove();
And got what APPEARED to be the same result (the circle is no longer displayed).
The only problem is that after some amount of time(seems random), my program freezes and I get the error message:
a1.paper is undefined
[Break On This Error] Raphael=(function(){var a=/[, ]+/,aO=/...eturn d;};an.el=ax[aY];return an;})();
Does this make sense to anybody? Am I calling remove incorrectly? How am I causing Raphael's code (on line 7 of the min file) to break just by calling remove on a circle?
It's difficult to know without seeing your code, but it looks like it is the Raphael canvas that isn't being found (I presume that's what a1.paper is).
Are you instantiating your Raphael canvas on document.onload (or $(document).ready with jQuery)? Make sure there aren't any closures in your code that make functions trying to operate outside the scope of a1.paper.
Then go right back to basics - try it with just a few circles to begin with, then 50, then 100. Then try it in different browsers and see whether it stops working in all of them. SVG is quite browser intensive, so creating thousands of circles might make some browsers break.
Related
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.
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)
I am working on a basic game in javascript. I don't use jQuery. The thing is that I have trouble in getting rid of the flickering. I noticed it happens because of the canvas clearing command. I read a lot of suggestions that recommended a sort of double buffering like having a buffer canvas on which I should draw which is not visible and another canvas which is visible and all the content is copied from the buffer. However, I doubt that even if I implement this I would still have the flickering as I still have to clear the visible canvas.
The final question is : What is the best way of getting rid of the flickering in my code? Thank you for your help.
this is a sample of my code:
http://edumax.org.ro/extra/new/Scratch.html
In your draw() method you call loadImages(), hence loading the images every time you redraw, ie every time the apple moves, hence the flickering.
Just put some breakpoints in your draw method it will all become pretty clear.
I guess what you want to do is to load the images at loading time then just draw... no need to load on every move.
I am experimenting with jQuery and the animate() functionality. I don't believe the work is a final piece however I have problem that I can't seem to figure out on my own or by trolling search engines.
I've created some random animate block with a color array etc and everything is working as intended including the creation and deletion of the blocks (div's). My issue is within 2mins of running the page, Firefox 4 is already at more than a 500,000k according to my task manager. IE9 & Chrome have very little noticeable impact yet the processes still continue to increase.
Feel free to check out the link here: http://truimage.biz/wip300/project%202/
My best guess are the div's are being created at a greater speed than the 2000ms they are being removed however I was hoping an expert might either have a solution or could explain what I am doing wrong and some suggestions.
On another note, from the start of my typing this out till now the process is at 2,500,000k. Insane!m
It could be a lot of things other than just your script there. It could be a mem leak in one of the jQuery things you use, pretty hard to say.
Something you could try is this though:
Instead of creating new squares, use a "square pool". Let's say you create 20 squares and just keep re-using them instead of creating new ones.
You'd basically just have an array for the pool and take elements out from it when they are displayed, and put them back to it when the animation finishes.
[edit]sigh... the "spam protection" here isn't letting me post the links, so I guess it's URIs instead[/edit]
[edit2]ok, BROKEN forms of the URI that can get past the regexp...[/edit2]
I'll preface this by saying I'm totally new to SVG, and somewhat new to Javascript, having come from a background in low-level C. On a whim, though, I decided to try my hand at writing a realtime game using all these fun new web technologies.
I'm fully prepared for the answer to be "The web can't do that yet, sorry!" This may simply be too much data throughput for a browser.
So I have written the beginnings of an Asteroids clone. It is a thin SVG document, with the entire game being dynamically generated as SVG line/polygon entities from javascript. Much to my surprise, this actually worked. I was able to get mostly smooth animation from Firefox 3.5 (not tested on anything else).
original, as-needed allocation version
(javascript) http - public.codenazi.fastmail.fm/asteroids_dynamic.js
This does variations of this each time a rock it hit:
// on startup
svg_ns = 'http://www.w3.org/2000/svg';
container = svgdoc.getElementById('rocks');
// each time a rock breaks, times ~20
x = svgdoc.createElementNS(svg_ns, "polygon");
x.setAttribute(...various things...);
container.appendChild(x);
Unfortunately, it's not smooth enough. It lags all the time. There are jerks and breaks in the flow, even on my modern 3GHz box. Several friends I have shown it to also immediately complained of stuttering.
I have spent the last week or so reading up on how to optimize javascript, which helped slightly, but I suspect that the issue is all of the insertions/deletions I am doing to the DOM for pretty much every action in the game. I have considered various pre-allocation schemes, and don't really want some complicated memory manager if it's not actually going to help.
What did come up a lot in my research is discussions of "reflow" and "repaint". As I understand it, any insertion/deletion to the DOM will cause some sort of re-parse of the entire tree, which is slow. The common solution was to collect sub-nodes together first, and only do a single insert into the actual document. This model doesn't really work with a game like this, though.
As a test, I sort of combined the two ideas: pre-allocate when possible, and insert in groups when possible. So in this version, each asteroid is replaced with a SVG group, and the asteroid, it explosion effects, and its pop-up score are created all at once. This way, allocations and insertions only happen when asteroids are created (not destroyed). To keep these extra effects hidden until they are needed, I set the "display: hidden" attribute.
new, group-preallocated version: http - public.codenazi.fastmail.fm/asteroids_prealloc.svg
(javascript): http - public.codenazi.fastmail.fm/asteroids_prealloc.js
When the rocks are created, this happens instead:
g = svgdoc.createElementNS(svg_ns, "g");
// make the rock itself
rock = svgdoc.createElementNS(svg_ns, "polygon");
rock.setAttribute(...various things...);
g.appendChild(rock);
// make the destroy effect (repeated many times)
frag = svgdoc.createElementNS(svg_ns, "line");
frag.setAttribute(...various things...);
frag.style.display = 'none';
g.appendChild(frag);
// actually add it
container.appendChild(g);
// then, sometime later when a hit is detected
rock.style.display = 'none';
frag.style.display = 'block';
I think this DID make it a bit smoother! But... it also dropped the framerate significantly. I have to keep track of more elements at once, and some testing has shown that wrapping everything in another element makes the SVG render slower as well.
So my question is this: is this even possible? Can I actually get a reasonably smooth SVG animation like this out of firefox? Or is firefox inherently going to have stalls/stutters? If it is possible, is there some memory/element management technique that can allocate/insert SVG elements in a better way than I currently am?
I kind of suspect that the answer will be to just stick with the first, easier method with fewer elements and wait for the future when browsers are better... -sigh-
I haven't tried SVG animation (yet); but Canvas is surprisingly good at it; especially if you do layers.
In short, create a canvas object for each layer, and erase/redraw each one separately. You can also do quick blitting between an off-screen canvas an the displayed ones.
I know, in theory SVG should be much quicker; but as you've noticed, the DOM parsing kills you. with Canvas there's no need for that.
Okay, first things first:
Dude - that is the most awesome bit of SVG I have ever seen. Thank you for sharing this.
It ran perfectly smoothly on my system, until I destroyed a whole bunch of rocks at once. What if you replace the dynamic frag animation with a pre-made SVG animation? Does that improve performance?