We Keep Coding

canvg not working in Edge

I am taking webpage screenshot of svg content using canvg. In Chrome, Opera and IE11 it seems to work fine, however in Edge browser it only weirdly renders black background with no content on the canvas.
Try it here in Edge browser
Open the link above and try the following examples
1) soccer
2) floorplan
I am unable to find the problem. Apparently looks like Edge is not supported by canvg. I hope someone already found a solution for this. It will be a great help!

There's more information about this issue here: https://github.com/canvg/canvg/issues/520
There is currently a merged PR that has not been released as mentioned in the issue and there's a workaround by monkey patching the code from that fix into the canvg code. You may want to subscribe to that issue so you know when the patch is released.

D3 Map Pan and Zoom Performance on Chrome

To make things easier, here is a JSFiddle of what I have.
TRY
In FireFox (version 35.0.1) pan the map. Click and hold anywhere on the map, and move it about quickly left and right. Panning movement should be quick and smooth.
Now try the same in Chrome and you'll see that it is not as smooth! It is a bit jerky/laggy. I find it laggy in the latest version of IE and Opera too.
By the way, if you comment out this style block, then behaviour all of a sudden smooths out and stops being laggy! You won't get a nice map of course.
#map path {
fill: #C9DCC9;
stroke: #066860;
}
SO WHAT?
First of all I would appreciate it if someone can confirm this behaviour on their PCs. I am on Windows 8.1 with all latest updates.
And then, why isn't this behaviour happening on other maps done with D3? This one for example behaves smoothly! Is it to do with the complexity of the polygons?

To fix this, I simplifed the paths of the map. I used the -simplification function on TopoJson.
After the simplification of the paths, the map panning and zooming was super smooth in Chrome, Firefox, Opera and IE 11.
TopoJson is a node package, so you would need to install node and a lot of other dependencies for TopoJson to get it working on windows. If you're lucky it'll work for you on Windows.
I was unlucky so I went and created a Virtual Machine running Ubuntu and in there, the node setup was soo much easier, I managed to do what I wanted in 5 minutes. Compared to days attempting to get this working on Windows.
Anyways, hope this helps. :)

html canvas animation stutter

Can anyone explain why the provided canvas animation stutters? I've created a test stub which demonstrates the problem.
I see the stutter in FF, Chrome, IE on desktop and in FF and Chrome on Android.
Is the stutter due to garbage collection? It seems even raf generates a double on each call which eventually requires gc. If gc is the cause then html5 animation is pretty much doa. Sigh.
The same question was asked a year ago but because I'm a new member I'm not able to contact the author to find out his solution. HTML5 Canvas DrawImage Stutter / Choppiness . It is really too bad there is no way for a new user to get another user's attention, since the author of that other question may have the information I'm looking for, an simply hasn't posted it. I tried posting to his question in an effort to get his attention, but my post there was deleted as a rules violation(which is was). Guess I'm out of options. Chicken and egg problem with rep.

Ok, so after pulling my hair out for 1.5 days I think I have an answer. It appears browsers vsynch to a monitor, which I guess is the point of calling requestAnimationFrame. It appears the synch mechanism can get confused when running on a multi monitor system. I have three monitors. When I disconnect all but one monitor and restart the browser, the problem appears to go away. This kind of makes sense given that the problem manifests sporadically, ie I'm guessing when a given monitor gets out of synch with which ever monitor is providing vsynch to the browser.
Since I'm not certain about this I'm hoping others can confirm or shoot down my theory. I'll continue to (re)test with different monitor configurations, but it would be nice to get confirmation from another brain and set of eyes.
Edit 01: I'm not completely nuts. http://news.softpedia.com/news/Firefox-Nightly-Adds-Support-for-Vsync-for-Smooth-Animations-360245.shtml
Edit 02: Some chrome users/devs has discovered this or a related problem. Finally something might be done with this issue. See https://code.google.com/p/chromium/issues/detail?id=422000. BTW, IE11+ does not have this issue. Started using IE11 for baseline testing, since chrome is having QA issues lately.
Edit 03: Just ran across this q&a which is similar. Good info in the first answer. Chrome requestAnimationFrame issues

HTMl5 and Canvas not drawing in IE9 (OR Firefox!)

So I have been working on a map system for Canvas, it all works fine in Chrome.
But Firefox and IE9 refuse to draw anything to the canvas... I can't seem to work out why.
The FPS count in the document title still works ok.
Here is my code so far:
http://www.barriereader.co.uk/tmp/neuroTile/
Has anyone seen this sort of non-error before? Where only Chrome draws on the canvas?
Thanks!!

Start by looking at the JavaScript console for error messages. It will tell you that document.width and document.height are not defined in IE9 or Firefox.

Performance issues with HTML to canvas, where to begin?

I have been working on an experiment to render HTML into a canvas image, by having javascript read all the necessary information from the loaded DOM. As canvas lacks many of the standard parts of CSS, especially when it comes to text formatting, a lot of work arounds and performance intense processes need to be done (letter-spacing for one). The intent is and never will be to make a fool proof HTML renderer, as it simply won't be possible, but instead try and make as accurate as it can be.
For the sample pages, Google Chrome usually loads them significantly faster than FF. However, for some pages (usually the bigger ones), Chrome completely freezes, where as Firefox loads them fine. Now, I have been trying to pinpoint where exactly things go haywire, but haven't had much luck as it doesn't end up outputting anything in Chrome.
Does Chrome have some limit of how many canvas draws can be performed within a certain time span, or how much system resources a page can use? How can I start untangling the bottleneck if I can't get any sort of feedback from the page at all (as it just hangs up)?
Examples (what it should do, is render a canvas image on top of the page, which should look more or less same than the actual HTML page. You can toggle the canvas image (show/hide) by clicking it. Please don't open them either if you got unsaved work in your browsers, as it may end up hanging them as well.):
simple test, works fine in FF/Chrome
another simple test, works fine in FF/Chrome
Complete page, works fine in FF/Chrome
Complete page, only works in FF < 4, Chrome freezes
They all use the same js which can be found here.
I am not looking for a blazing fast script, as with the type of emulation this renders the images, I don't think it could even be done. Simply trying to find ways to make it perhaps slightly more efficient, without losing any of its current functionality.

Where to begin?
Break it down.
Use the same example and cut how much you do it it (your rendering code) in half. Does it still not work? In half again, etc. Did it work? Put back half of what you took out.
As in, get rid of all attempted text rendering, or all border/padding code. Just comment it out. Does it work then?
Or try just commenting out ctx.drawImage(img,x,y); on line 199 and nothing else. Does it work then?
If you're lucky you'll be able to determine a critical point where Chrome is spending a lot of time doing something.

Have you tried using Chrome's built-in performance profiler?

The problem appeared to be with the css attribute background-repeat, and specifically repeat-x. Commenting out
for(bgx=(x+background_position_left);bgx<=w;){
drawImage(image,bgx,(y+background_position_top));
bgx = bgx+image.width;
}
Fixed the issue at least for chrome, and looking at that it most likely was an endless loop as Kinlan proposed, but why exactly it gets stuck only on newer versions of FF and chrome is something I'll need to look more in detail (most likely not having the image.width available yet, or something similar).