JS gfx antialiasing

[ph69]

Hi,

Just a little problem that arises with anti aliasing.

When I draw a curve with many line_to,
the last pixel of the former line and the first pixel of the next line, are the same. So, this pixel is drawn twice.

With antialiasing, the pixel is transformed into transparent pixels. These are drawn twice and it looks as if there was no antialiasing.

The same pb arises in additive mode. The joint pixels are drawn twice and are brighter than others.

Maybe, a polyline primitive or an option on gfx_lineto can prevent this side effect.


JS is really great !
Bye ;)

[schwa]

JS graphics code, as well as fft and some other stuff, is run off of Cockos LICE and WDL (http://www.cockos.com/wdl/) which is an excellent open source graphics engine and utility library.

(IMO the excellent thing about them is that unlike other similar offerings, they are relatively humble, that is, rather than trying to provide a superelegant high level interface that falls apart as soon as you try to extend it, they instead provide a lot of fairly low-level and very flexible functions, which means, as the web page says, that it tries very hard not to get in your way.)

Anyway, I contributed the line antialiasing code. The antialiasing-blend-mode-line-overwrite problem you describe is a hard problem not just limited to endpoints. Like imagine drawing a line from (a,b) to (c,d) and another line from (c,d) to (a+1,b+1) ... most of the antialiasing of the second line would clobber the antialiasing from the first line. The only solution I can think of just now would be to composite in two stages: stage 1 would be a special max-blend mode for just the lines, where a pixel is drawn at max(existing color, new color), so a new line's antialiasing can brighten an existing line's antialiasing but not make it brighter than either line's non-antialiased color. Then the whole composited line image would get composited against the background using any other blend mode. This whole process could be wrapped in a polyline function as you suggest, but you'd have to handle every pixel twice and it would be costly.

For an efficient way to handle just endpoints, maybe the thing to do would be to add a separate line drawing function for [a,b) lines, which clips the line to a box that doesn't include b and then draws it. But you'd still get antialiasing interference problems for joined lines that meet at acute angles.

[ph69]

Antialiasing it is a difficult problem...
In audio
And in the computer graphics realm too ;)

By the way, do you take account of the gamma (sRGB) ?

That's just details, if we consider that almost no other software takes care of graphic antialiasing (see the VST gui SDK... well maybe the latest deals with it).

[schwa]

By the way, do you take account of the gamma (sRGB) ?

No, I don't believe there's any gamma-correction in LICE.

That's just details, if we consider that almost no other software takes care of graphic antialiasing (see the VST gui SDK... well maybe the latest deals with it).

You can bolt gdi+ to vstgui but both APIs are restrictive and gdi+ is a performance killer.

[ph69]

We can go OpenGL :D
Most graphic cards implement "blend antialiasing" for lines and polylines. :D Just kidding.

[schwa]

We can go OpenGL :D
Most graphic cards implement "blend antialiasing" for lines and polylines. :D Just kidding.

Antialiasing in OpenGL isn't straightforward either! Actually there's some interesting support for OpenGL in WDL ... there's a class for mixing OpenGL and regular GDI calls. I believe ReaFIR used to use this code, but now it uses LICE because it's just as fast, and not dependent on user hardware specifics (which is the killer with OpenGL).

[ph69]

I played with OpenGL 6 years ago and antialised lines are supported since the GeForce3. It is a standard OpenGL mode, not a specific extension.
I will give a look to LICE as soon as possible.

Yesterday I improved the antialiasing in ScopeII.
See the JS repository for the latest version ;) it is included in the MoonSynthi package.