We Keep Coding

Any way of making Kinetic.js support IE8?

I am in a situation right now where I need to have some complex code working with Kinetic.js and a canvas element to work on IE8.
Officially, Kinetic.js has no plans of supporting IE8.
I tried using webshims lib but Kinetic.js fails on the following code:
Kinetic.Canvas = function(width, height) {
this.element = document.createElement('canvas');
this.context = this.element.getContext('2d'); //<-- Error here
// set dimensions
this.element.width = width;
this.element.height = height;
};
The error is "Object doesn't support property or method 'getContext'". It makes sense to me, since I would not expect the element canvas created by an IE8 document to implement the methods for a canvas element, but if the <canvas> element was already created, webshims would have played and you could use the methods. However, forcing Kinetic.js to use one single canvas element will break some of its functionality (since it creates canvas objects on the fly).
Which are my options in order to achieve this?

The simple answer is "no."
As one commentor mentioned, Google Chrome Frame is an OK substitute, which entails essentially installing Chrome's rendering engine as an IE plugin.
There's the excanvas project, which might sound good at first. It was an attempt to implement canvas in VML (SVG) so that IE 6-8 could use canvas.
Excanvas is awful. Especially with any animation, and it cannot do some canvas image manipulation stuff. And it hasn't been updated in almost 4 years. I highly suggest against using it, but it's there for your consideration.

Should the Canvas globalCompositeOperation modes work from drawImage?

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

How to generate simple 3D images in JavaScript

I like to generate a simplified version of the following static image in pure JavaScript. It should work with 2010 vintage browsers, so I can't wait for Firefox 4 and WebGL.
I do not need any fancy textures - the task is just to visualise how to stack some boxes.
BTW: the current image is generated with POV-Ray which is overkill for the job - and does not run in the browser ;-)

As you say you don't need fancy textures I'd recommend for vintage support that you stack images like mentioned earlier. I made an example for you: http://jsfiddle.net/andersand/5RsEx/
The simple function is just to illustrate, and does the drawing of a segmented box. Of course you may need to figure out box placement, orientation, and so on if that is your business goal.
That approach could help you with boxes of various height (z axis). If your boxes also vary in width (x and/or y) you'd need to create more images to suit your needs.

If you can do without IE support, or require a plug-in for IE users, or provide server-side rasterization for IE users, you could use computed svg files.
You could do a very basic projection of the vertices of the boxes, maybe start with a simple isometric projection and then go to a perspective projection. Use simple 4x4 matrix math as used in OpenGL for this and represent the 3D coordinates as [x, y, z, w] vectors. Since the images are small and simple enough you can get away with simply using a smart rendering order, i.e. bottom to top, back to front, which will make sure you don't have to worry about mucking about with a depth buffer or other such things. Should be fairly simple to implement, you don't need third party libs and it will be natively supported in most of the contemporary browsers.
Okay, I thought this to be an interesting experiment, so I made a working version of what I described above. It works in all major browsers with the notable exception of IE. SVG support should come to IE with the introduction of IE9. I've tested in Opera, Firefox and Safari under OS X and Opera and Firefox under Linux. It might be possible to add IE support by making VML output possible, though I must say that I do not know whether IE permits inlining of VML in XHTML using namespaces like I used here.
Computed SVG rendering of 3D stacked boxes
Right now it only does isometric projection. I might just spend a bit more time on this to add a perspective projection option as well. That would seem fun and should not be much more than adding another matrix multiplication.

Searching for Collada (XML based 3d file) support may be your best bet. Now that canvas has landed, lots of 3d routines are being ported from Flash Actionscript to Javascript.
You can export Collada files from all of the major 3D applications, as well as blender ;)
Try the following as an example;
http://www.rozengain.com/blog/2007/11/21/parsing-collada-3d-assets-with-javascript-in-the-html-5-canvas-element/
If you want to rotate a 3D scene using javascript, you may have a few months wait until the engines get released. They will most likely be HTML5 dependent.
There are a few WebGL implementations doing the rounds but they are for the bleeding edge browsers and are very unstable.

Canvas and HTML5: Supported Browsers?

I am looking at using HTML5 Canvas element for my upcoming project. I want to know what all major browsers (including the versions!, cos i know that the latest builds do support canvas) support the Canvas tag. I don't give a damn about IE. So don't bother reporting IE. :) In this tutorial Drawing shapes - MDC, the quadraticCurveTo section says:
quadraticCurveTo(cp1x, cp1y, x, y) //
BROKEN in Firefox 1.5 (see work around
below)
Does that mean that Canvas is supported on Firefox 1.5 and above too?

caniuse.com lists browser support for many different features, including canvas.
Specifically, browser support for canvas is listed at caniuse.com/#search=canvas.

It's not only about "supporting Canvas", but about the bugs that each implementation has about this and missing methods that have been added since the initial release. So even if one version of Firefox does add the basic Canvas support, it might have some bugs that make it impossible to use it in your application.
In that case, you might need to check the current versions and then go back as far as you want to support to verify if they work as expected.

How does Javascript CANVAS works?

Javascript CANVAS is amazing: it allows us to draw something like lines, polygons on the browser screen.
I wonder how does Javascript CANVAS works. For example to draw a line, does it use a series aligned tiny images to simulate the line or some other approach?
Thanks in advance.

Any reasonable implementer would just use a bitmap (stored internally in the browser), and draw to that using OS native drawing commands.
Why does it matter? It's not at all related to HTML+CSS, if that's what you're wondering.
More detail, for detail's sake:
When the browser's HTML parser sees a canvas element (of a given width & height) it needs to allocate an onscreen pixmap to cover that area. It either does this manually (i.e. malloc()) or it calls into some OS native drawing API to create a surface to draw on. The OS native API could be Windows, Gtk, Kde, Qt, or any other drawing library that the implementer of the browser chose. Also, it's highly dependent on the operating system. Internet Explorer probably calls into some Windows native library (i.e. DirectX or WinFooBarMethod()).
Once the drawing surface is created, it's made accessible to the internal guts of the JavaScript interpreter, likely via a pointer or handle to the constructed drawing surface. Then, when the JS interpreter sees an invocation of one of the canvas methods, it turns this into a call to the appropriate OS native command.
So, using the Windows 3.1 style metaphor:
"new canvas(width, height)" = "WinCreatePixmap(width, height)"
"canvas.setPixel(x,y,color)" = "WinSetPixel(x,y,color)"
And using a manually managed pixmap:
"new canvas(width, height)" = "malloc(width * height * sizeof(Pixel))"
"canvas.setPixel(x,y,color)" = "canvas[x][y] = color;"
Again, it shouldn't matter to the JavaScript developer how these methods are implemented. The only people who need to care are the ones who are writing HTML5 compliant web browsers with canvas support.

If you know C++, you can go to the source.
For example, in Firefox, the "graphics context" object is implemented by the class nsCanvasRenderingContext2D. But that class doesn't actually modify the pixels directly. Instead, it asks a separate object, called Thebes, to do that. Thebes in turn delegates this work to a graphics library called Cairo, which typically asks a library provided by your operating system to do the actual pixel work. I imagine it's a similar story everywhere.
At the very bottom, the canvas has a two-dimensional array of pixels. Each pixel is a 32-bit integer. A pixel is set by assigning a value to an element of the array. Somewhere there's a bit of code that determines which pixels to paint and assigns the appropriate values to the appropriate array elements.
In theory, the pixels might be drawn by your video card, but I have heard that graphics cards generally can't be trusted to do 2D graphics, because the hardware is aggressively tuned for 3D gaming and trades away too much accuracy for speed.

If you're interested in how line drawing works, check out Bresenham's Line Drawing Algorithm.

Surely that's implementation-specific to the JavaScript engine browser in question?

You're thinking too much, it's simple:
A canvas is like an image that can be drawn on to the browser.

I think implementation is important. Why does it matter? Look at flash. When you use the drawing API to create complex fractal artwork it is actually creating vector artwork and making every line and curve a child of the object being drawn on, thus it rerenders the vector artwork every frame.. CRASH! or chug... chug........ chug..............
So for complex fractals or art that records equations, I have to use a Bitmap or the render engine CACKS. It DOES make a difference, since now I am trying to transfer some of my flash multimedia to Javascript and encountering differences among browsers.