I'm really not sure of the history, but pixel shaders must have been invented in the 60's. One of the things that has always drawn me to computer programming is the ease in which you can make cheezy gratuitous math based graphics. With pixel shaders it is like you have a brand new Commodore 64 all over again.

I've modified the bouncing circles program (all shader no triangle) to select different shaders using the space bar (download here), but the real fun comes when tweaking the code yourself. Especially when combing things, and more so on multiple passes. These basically get the distance between each moving point, and then do some math, always truncating the result to be between Zero and One.

Here are a few points of interest I've been stumbling over... Optimizing is really unintuitive - hard stuff (distance, matrix manipulation, trig, etc) tends to be really fast as it is mostly hardware. But then easy stuff (like if/else) can be very slow. At least for shader 2, there is no flow control - it is simulated by running both paths and then nullifying one. So at one point I tried to optimize things by throwing out circles that were too far, and it totally slowed down! So switching between effects is much faster if you have 20 different effects, rather than one effect and an index (say like a switch statement equivalent in your pixel shader).

In spite of these cards being able to do floating point math like a hungry animal, it is still going to be tricky to do Flash style animation. I was thinking potentially some kind of ray tracing technique on to optimized bezier data, but seems like it will be too slow. Then the brute force triangulation seems like it will have too many triangles (an outlined donut took 300+ triangles to look reasonable full screen - compare that to a swf with 100s of much more complex shapes and tricky fills).

I am thinking one way to get around the jaggeds would be to use a static number of vertexes per shape, and as it zooms in (and part goes off screen), reuse the unseen vertexes in the visible area. This would require recomputing the locations, but that could be done in the vertex shader if the vertex count is constant. That being said, it still requires a large number of points, so you would probably have to reset the point count based on zoom and complexity. Ideally you could say, here is your frame, use the 500,000 vertexes you already have to render it. Maybe that means 500,000 vertexes in a buffer that doesn't change, maybe upload new indicies when things change radically, and only your draw calls happen every frame. Eg. you have 2 circles of 30 vertexes each, then change them to 3 circles or 20 vertexes each - same vertexes and maybe same index buffer, just three calls to draw triangle fan, as opposed to two calls. Hmm, anyway, lots of testing ahead.

Well, here is the download if you want to waste some time, requires Pixel shader 3 on your card (new-ish) and the XNA runtime stuff.

Download