OpenGL InkCanvas coming right up

Well, it's part way there...

What I've got now is a cross platform system:

Erlang launches and links in a port driver, using a slightly modified ESDL.
The window is created in pure OpenGL, with SDL handling the event callbacks.
Every event gets passed back up to Erlang, where strokes are collated.
Erlang sends accumulative drawing instructions as the pen moves, then does a full redraw when the pen lifts.

That all works, and is nice.

The main question now is, how can I make my ink look as nice as microsoft's? They've put a lot of work into theirs, and it shows.

Here are my thoughts:

Ink quality is a combination of: Pressure representation, ink flow representation and fluid edges.

My first try involved drawing GL_LINE_STRIPS, thickening the line segment according to the pressure at the end vertex. That looked... Crude, to say the least. It was nice and fast, but quite aliased. Turning on antialiasing for ink DEFINITELY didn't solve the problem, and it looks like most graphics cards might be deprecating glLineWidth. Apparently all OpenGL compliant devices must support a width of 1, the rest is hope. Nevertheless, I kept plugging on that for a bit, went through building a gaussian fragment shader to soften the edges. Only a 3*3 kernel, I must admit. Helped a little, and gave a nice impression of blue ink in the way the color suddenly varied wildly across the stroke, but didn't make it much less jaggeddy.

I also tried drawing multiple layers of lines, for a sort of transparent bleed effect at the edges. Looked ok, but was still not antialiased so suffered quite badly from being either 1 or 0 pixels extruded from the overlying stroke.

The current attempt involves taking the original line coordinates and building quads around them. The advantages of this are:
They're hardware accelerated in a way that lines might not be.
They can be textured. Lines cannot.
They don't suffer from the aliasing problem in the same way, and have float precision angles. This makes for much nicer sides.

Problems with it?
It's hard to calculate, so as we get hundreds of strokes on the screen it might slow down badly.
At the moment there's some cockup with the trig where a particular angle (ENE or SWS on a compass) has visible end swapping - the outer line becomes the inner and vice versa.

We'll have to fix that. Stu will have to fix that, in fact. He's my trig monkey, and much loved for it.

Screenshots coming up, depending whether there are any convenient tools for clipping in Ubuntu.

Oh, btw I just found out that Awesomium hasn't released its Linux port yet so might have to move primary dev of this either back to Windows or to mac. Probably mac. It just seems crazy to try for cross platform but develop on windows.