We Keep Coding

How to antialias strokes drawn in canvas without using clearRect

I am working on a drawing app as a personal project (currently living at http://draw.ist/) and I'd like to get the drawn strokes smooth around the edges but it seems the only way to accomplish this is using clearRect. However, clearRect also clears the canvas every time I start a new path and I'd like to prevent that so the canvas actually accumulates the strokes.
I've seen stuff about creating a secondary canvas to save strokes to or something so the clear doesn't wipe them (at least I think it works somewhat like that) however that method would require a lot of additional code that I'd like to avoid. Most recently I've tried saving the canvas as an imageURL on mouseup and then re-placing it with drawImage right after every clearRect, and this seems to do the trick nicely but it has some bizarre interactions with my eraser and straightline tools, as well as some flickering every time it loads in the saved canvas image.
There isn't necessarily any particular snippet of relevant code here, but for reference the entire site can be found at http://draw.ist/ (Controls: hold shift to draw straight lines, hold spacebar to erase, scroll mousewheel to change brush size)
I'd like all drawn lines to be smooth and have antialiasing but without using the "secondary canvas as memory" method IF POSSIBLE. I think what could help me here as well is understanding why exactly clearRect is necessary to apply antialiasing to strokes in canvas and how it works exactly in layman's terms. I greatly appreciate any assistance on this, whether it's actually helpful or not!

Finding most common color of an image

I have a bunch of products on a page that have 200x200 images. My first run at this was to get the data for each pixel (nested for loop, one for x, one for y), then convert rgb to hex, and store them in an array and then get the most frequent one. This script needs to run on 96 items per page at a time.
Currently, it creates a canvas and puts the product image in that canvas and then performs the above operations.
Is there some kind of averaging algorithm that would make this faster?

Yes!
Lokesh Dhakar has created a script called "color thief" that calculates the dominant color of an image. It uses the modified median cut quantization algorithm (MCCQ) to quickly cluster colors and determine the dominant color (or even the whole color palette).
There is a demo here: http://lokeshdhakar.com/projects/color-thief/ and the script is available on github here: https://github.com/lokesh/color-thief

I know it sounds easy to use library and all, but i found a much simpler solution that pretty much serves the purpose.
When you apply a blur filter what it does is takes the average of pixel intensities. So if you apply a blur to the image with pretty high pixel value like
filter:blur(30px);
or
filter:blur(50px);
or anything that suits, it average outs the entire image and provides you with a solid background color which is most of time the prominent color from the image.
Its much simpler to do, and should work almost always. Just try tinkering with the blur amount.
Also remember to set overflow-y to be hidden because high blur causes white padding outside the image. hiding the overflow will fix that.
Hope that helps :)

Rendering on html5 canvas takes cosumes too much time, buffering barely helps

For a game, I'm trying to calculate light and shadows. For this, I break down my canvas into square areas and calculate, if a light ray would be blocked on the way from the player to each square position. I've managed now to reach a reasonably good performance for those calculations.
The results are then visualized by covering non-visible areas with dark squares (Canvas.fillRect(...)), but this step becomes too expensive when a want a nice resolution, i.e. ~10'000 squares for calculation. I've tried to first render them into an off-screen canvas (=buffer), then draw the buffer on my visible canvas, but I could not experience any remarkable performance improvement.
Is there something I missed, or are there other methods to fasten up drawing?
Update:
The affected code can be found here: https://github.com/otruffer/Ape_On_Tape/blob/master/src/client/js/visibility.js (Code is a bit too big to post here)
The actual drawing takes place in drawCloudAt(...) and flushBuffer() in the lower part of this file.

Doing real-time light calculation in software is always a performance killer. Did you consider using a real 3d engine instead which does the light calculation on the video card? Yes, Javascript can do that now - this new feature is called WebGL.
When you just need a faster way to apply your lightmap, you could manipulate the RGB values of your canvas directly instead of using fillRect. You can use getImageData to get an array of raw 8 bit RGBA values of your canvas. You can then manipulate this array and put it back with putImageData.

Pixel-by-pixel animation with javascript

I'm animating a sprite on a pixel grid. I have a few options, with pros and cons for each. I have a fair amount of javascript experience (six years), but none with this kind of thing. The problem is I don't know how expensive each option will be.
The sprite needs to render quite fast, and be inexpensive enough to have at least five running at the same time while running collision detection.
Ideally, I would like to use a grid of elements inside of a wrapper, rendering colour and alpha channels to each element from a multidimensional array.
The major pro here is that I can run pixel-by-pixel collision detection and click past the transparent parts of the sprite. With any image-based sprite, the onClick event will fire even if I click on a transparent pixel (I'll have to do a lot of work to pass clicks through transparent pixels, and it might be quite expensive).
The next option is to use css sprites. css-tricks.com/css-sprites/
This would be easy peasy, but as mentioned previously, onClicks won't pass through the transparent pixels. I can probably force it, but again, it may be expensive, and take a lot of time to impliment.
Another option is animated gifs, but they are huge, limited in the colour department, and hard to control animation-wise. I'd rather not go there.
And then there's the html5 canvas element, which I don't know very much about and would like to stay away from if at all possible. I don't know how any of my code would even work in relation to the canvas element and I doubt it would do what I want in the long-run.
So which is the best for performance? Would the first (and most preferable) be a viable option? Or have I missed something out?

With today's browsers you will be fine on desktop computers for building a sprite out of positioned pixel sub-elements (as long as they aren't too complicated or large), and just to be safe I'd limit yourself to about 10 active sprites. With Mobile things might get a bit slow and clunky, but considering you seem to be designing a game that requires precision "onclicks" I doubt that this will be a problem.
Your most flexible bet is to use HTML5 Canvas, as you have already worked out, but it will involve quite a bit more JavaScript coding. But this sytem will allow you to apply a number of effects to your sprites and will allow you to use pixel perfect detection by using getImageData (which allows you to read the exact pixel colour at any pixel offset).
getPixel from HTML Canvas?
If you wanted to avoid the techinical problems and challenges of having a full screen canvas system (which can be tricky), you can actually create as many smaller Canvas elements and move them around as your sprites (with the ease of HTML Elements).. Then all you have to do is design the code that draws your animation frames, and also tells if the mouse has hit or not hit the sprite using the aforementioned method (along with a click handler and some code to calculate where the user has clicked relative to your canvas elements position). Obviously, it would be best to do this in a generalised way so your code can be applied to all your sprites :)
To draw your images on the canvas you can use a spritesheet as you were mentioning in your question, and use the rather flexible drawImage() method which supports a slicing mode. This just needs to be tied up to a setInterval or requestAnimationFrame style game loop.
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Canvas_tutorial/Using_images
http://www.playmycode.com/blog/2011/08/building-a-game-mainloop-in-javascript/
UPDATE - for those who wish to be very optimal
If you wish to take a more optimal route - which is a little bit more involved again - you can do the following. This method benefits if you have many sprites that are exactly the same with only a few (20 or 30) frames of animation:
Power your sprites by normal DIVs with a background image sprite sheet that you shift the background position of. This is the most optimal you can be, save having static images as sprites, because the browser does all the work.
for each sprite type draw your spritesheet on a hidden canvas element that is big enough to incorporate your whole spritesheet.
When a user clicks on one of your DIV sprites, take the background position as coordinates, invert them, and you should then know where on your canvas element (looked up by sprite's type) the pixel data resides.
Use the getPixelData method on your hidden canvas to work out if the user has clicked on the sprite or not.
The above means you only have one canvas element in use - per sprite type, the browser handles all the graphics for you and you get pixel perfect collisions with an onclick.
Hope the above makes sense?

How about splitting your image spirit into 30x30 cells and only have elements where the cell is opaque and leave a gap where the cell is transparent so that clicks fall through. You lose a bit of accuracy in where the cells can be clicked though.

canvas tile grid with hover effects, tilesheet, etc

I've been working on building a tile-based display grid for canvas. This is what I have so far: http://jsfiddle.net/dDmTf/7/
Some problems I'm having, and can't quite grasp are:
The initial load time is ridiculous... I don't understand what I'm doing wrong - fixed, found out I was rendering ^32 more than I was supposed to
The hover effect, which "should" just highlight the border of the tile, erases it, and I have no way of recovering the previous tile without re-rendering the entire canvas.
How do I use tilesheets, providing me a single image instead of a bunch of small ones
Resizing the window (which resizes the canvas) also erases the canvas. Do I need to re-render? Or can I maintain state of various things when width/height is changed - added an onresize callback, which re-renders the map. Might not be the best way though?
Multiple layers? How would I go about allowing transparency .png files overlaying each-other
Those are the main problems I'm stuck on right now, and any guidance would be majorly appreciated.
Also, if you have any pointers for my javascript, feel free! I'm learning it more as I go, and I'm sure I'm doing a lot of things wrong.
Edit
As an FYI, I just copy-pasted the sprite map currently being shown on the jsfiddle. It's not the one I'm planning to use, but it was easier than uploading one. I plan to maintain a 32x32 grid instead of (what appears to be) a 16x16 grid from that tilesheet
Edit
I've got the a 32x32 tilesheet displaying on there now, but the hover effect is still breaking it, and I'm not sure how to "know" what the old value was.

The problem is that you are not redrawing your tiles after 'mouseout'.
You either need to redraw the single tile after you move out of it, but this can get tricky as things get more complicated or better yet on mouse move do the following.
Clear the canvas
draw the grid
draw your tiles
then do the highlighting/clearing that cell.
If you end up having any sort of animation this is the process that will be used anyhow otherwise as something moves from one tile to another it will leave ghost images behind.