BBC BASIC for Windows
Programming >> Graphics and Games >> Antialiased thick lines
http://bb4w.conforums.com/index.cgi?board=graphics&action=display&num=1319407812
Antialiased thick lines
Post by admin on Oct 23rd, 2011, 10:10pm

I've uploaded this demo of plotting 'thick' antialiased lines:

http://www.rtr.myzen.co.uk/thicklines.exe

The line thickness cycles between 2 pixels and 20 pixels. The ends of the lines are 'square' and (of course) are also antialiased.

As far as I know the technique used is original; it is not based on any graphics code or algorithms found on the web.

Richard.
Re: Antialiased thick lines
Post by David Williams on Oct 23rd, 2011, 11:12pm

on Oct 23rd, 2011, 10:10pm, Richard Russell wrote:
I've uploaded this demo of plotting 'thick' antialiased lines:

http://www.rtr.myzen.co.uk/thicklines.exe

The line thickness cycles between 2 pixels and 20 pixels. The ends of the lines are 'square' and (of course) are also antialiased.

As far as I know the technique used is original; it is not based on any graphics code or algorithms found on the web.


Splendid! Well done. They look beautiful.

You seem to have solved the technical problem you recently mentioned.

Relatively low CPU usage as well, I notice.

I take it the lines get safely clipped at the window/framebuffer edges?

If you ever feel tempted to compare drawing speeds with the GDI+'s thick-line plotter, I'd be interested in learning the result.


David.
Re: Antialiased thick lines
Post by admin on Oct 24th, 2011, 08:19am

on Oct 23rd, 2011, 11:12pm, David Williams wrote:
You seem to have solved the technical problem you recently mentioned.

No, I couldn't think of any simple solution, so I simply ignored it! Although it means the antialiasing is only strictly correct when the edge is near horizontal or vertical, and is a bit out when diagonal, in practice I'm not sure the difference is sufficiently visible to worry about.

Quote:
I take it the lines get safely clipped at the window/framebuffer edges?

My algorithm simply determines whether a pixel should be plotted fully (i.e. opaque at full amplitude), antialiased (i.e. blended) or not at all. Pixels 'outside' the frame buffer are never passed to the algorithm in the first place!

I don't claim it's a particularly efficient method, but it does guarantee that each pixel only gets plotted 'once' (which isn't the case for either your or my 'thin line' code) and means clipping to the window/buffer isn't an issue.

Quote:
If you ever feel tempted to compare drawing speeds with the GDI+'s thick-line plotter, I'd be interested in learning the result.

I'd expect GDI+ to be faster, but I haven't tested it.

Richard.
Re: Antialiased thick lines
Post by admin on Oct 24th, 2011, 11:32am

on Oct 23rd, 2011, 11:12pm, David Williams wrote:
If you ever feel tempted to compare drawing speeds with the GDI+'s thick-line plotter, I'd be interested in learning the result.

I'm having some difficulty making a reliable comparison using Task Manager, in part because the CPU usage of my demo program is quite variable depending on the angles and thickness of the lines.

Using the profiler, with my code 5.8% of the total time is taken up actually drawing the lines to the memory DC and 4.2% in transferring the DC to the screen. With GDIPLIB (generating an 'identical' output) 11.3% of the time is spent in the library.

On that basis they are quite similar, but I can't trust the comparison because the InvalidateRects are doing quite different things. To make a more accurate comparison I'll need to hack GDIPLIB so it doesn't do the InvalidateRects.

Edit: With the InvalidateRects eliminated from the comparison, mine is spending 5.8% of the time drawing the lines and GDI+ is spending 6.4% of the time drawing the lines.

Richard.