On 12 Mar 2000, Marcus Sundberg wrote:
[on antialiasing in libGGI2D -> clipping for brevity]
> > I'm not actually sure that antialiasing is all that in use outside of
> > fonts and some imaging apps. Comments?
>
> Well, fonts do not belong in LibGGI2D.
> And antialiased drawing doesn't belong there it is not hardware
> accelerated (on most hardware, IIRC I've heard about next generation
> 3D-cards supporting antialiased edges), and because the software
> implementations would be very different from normal 2D drawing.
so let's see:
- 3D antialiasing in some hardware
(incidentally, points, lines, and triangles)
- 2D antialiasing is not in hardware...
actually it's easily implemented in hardware and
easily constructed using hardware accels, but that's
not the same
I believe it's [alpha + linewidth/pointwidth] is all
that's needed....
I've never seen how hinting affects antialiasing - but I can believe it...
(controlling which lines/edges/etc are antialiased)
... I've coded antialiasing code before. It's no big deal. The
complication is that -how- antialiasing is handled is dependant on what
you're drawing. points, lines, circles, triangles are all handled
differently...
/change topic : heya just had an idea on how to handle this :)
Request: add pens to libGGI2D requests!
(and not in libGGI -> that should handle window requests + maybe buffer
requests and maybe some fallback render ops just to keep things working.
libGGI2D should be accelerated)
Pens ->
pen width == line and point width
pen colour == well :)
pen stencil == ... yes 3D stencils are unfeasable. This is for 2D
pen write op== how to write pixel
pen read op == how to read pixel
I'm getting carried away.... but this would happily handle antialiasing
at some later date + all HW accels I've seen specs for... (antialiasing
accelerated in external app that uses this :)
G'day, eh? :)
- Teunis
