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.
Related
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.
I have a scene in threejs that worked perfectly in Firefox two weeks ago. Today, after updating Firefox recently, I opened up the exact same file, and now I see a very brief flash of the image and then I get a completely blank, white page. It's all local code, relying on a local, downloaded version of three.min.js, so I'm positive there have been no changes to the files.
The examples on the three.js website work fine, so I don't know why my local files would be misbehaving in the latest version of Firefox.
Does anyone know of any changes recently to Firefox that interact poorly with three.js? How to fix it?
[Working fine in Internet Explorer 11. In Chrome, scene appears, but the textured cubes are missing or invisible.]
I decided to play around with Canvas and SVG this morning so I could learn about these elements more. So I came up with an idea to copy an image from a canvas element and convert it to a bunch of SVG rects.
It was pretty simple but I found a strange bug in Chrome: most of rects are colored green!
Here is a sample: http://codepen.io/anon/pen/iKvBe
Look at it in Chrome and Firefox. Any idea what is going on?
thanks
It works on occasion. But it is clearly a JS/V8 optimisation bug. You should report it as a Chrome bug.
https://code.google.com/p/chromium/issues/list
http://jsfiddle.net/MP4Yg/5/embedded/result/
Heres a plugin I've been working on to create Hub-Spoke diagrams. I've avoided asking any questions pertaining to this so far (gonna go ahead and pat myself on the back for that one) but, I've now hit a roadblock...
My functions are working great but for some reason only in chrome (and partially in opera). I'm using <canvas> to draw lines between circles, none of which render outside of chrome. I want this to work in at least IE 8+, and it should work in updated FF and Safari, etc.
I'm also self taught on all of this so any suggestions and feedback on my code would be appreciated, although I'm not sure this is the place for that.
I am using globalCompositeOperation = 'copy' then a drawImage so that my new image replaces what is underneath.
This works fine in the latest Safari and Chrome browsers on Mac and Windows and also on the iPad.
It doesn't work in IE 9 and while it works in Firefox 3.6, it doesn't work in Firefox 4.0.
What seems to happen when it isn't working is the whole canvas gets erased, not just the area in the rect I pass to drawImage.
I think this is a bug in IE 9 and firefox 4.0 but should I not expect it to work?
These are the images of what Mozilla is assuming the Canvas is supposed to work:
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Canvas_tutorial/Compositing#globalCompositeOperation
The problem is that the spec is written rather vaguely here. For example, for the copy composite type, it reads:
Display the source image instead of the destination image.
Which could be taken to be a synonym of source-over, or it could be taken to mean "clear the entire canvas and then copy the new drawing operation onto the canvas"
To see how the different browsers differ in their implementations, use the images provided by mozilla above with this live-firing (not images, canvases) of all the different composite shapes that has also provided by Mozilla:
https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.html
Just looking quickly it seems that Chrome 11 disagrees with Firefox 4 on source-in, source-out, destination-in, destination-atop, darker, and copy.
It seems at a glance that the thing to note is that all of the differences are related to whether the non-pertinent pixels should be cleared or not. Mozilla seems to think so, Google does not.
When you use drawImage() with globalCompositeOperation="copy", it's unexpected that the canvas is cleared outside the destination rectangle. But this seems to be the consensus of how to interpret the standard. Even with fillRect() or when drawing a line, the whole canvas is cleared. You have to set a clipping region to prevent that.
For a discussion see: https://bugzilla.mozilla.org/show_bug.cgi?id=366283