Why is drawing a line less than 1.5 pixels thick twice as slow as drawing a line 10 pixels thick?

Question

I\'m just playing around with FireMonkey to see if graphical painting is any faster than GDI or Graphics32 (my library of choice at the moment).

To see how fast it is, I

Answer 1

In other libraries there seem to be fast algorithms for single lines, and thick lines are slower because a polygon is created first, so why is FireMonkey the other way around?

In Graphics32, Bresenham's line algorithm is used to speed up lines that are drawn with a 1px width and that should definitely be fast. FireMonkey does not have its own native rasterizer, instead it delegates painting operations to other APIs (in Windows, it will delegate to either Direct2D or GDI+.)

What you are observing is in fact the performance of the Direct2D rasterizer and I can confirm that I've made similar observations previously (I've benchmarked many different rasterizers.) Here's a post that talks specifically about the performance of the Direct2D rasterizer (btw, it's not a general rule that thin lines are drawn slower, especially not in my own rasterizer):

http://www.graphics32.org/news/newsgroups.php?article_id=10249

As you can see from the graph, Direct2D has very good performance for ellipses and thick lines, but much worse peformance in the other benchmarks (where my own rasterizer is faster.)

I mostly need single-pixel lines, so should I paint lines in a different way maybe?

I implemented a new FireMonkey backend (a new TCanvas descendent), that relies on my own rasterizer engine VPR. It should be faster than Direct2D for thin lines and for text (even though it's using polygonal rasterization techniques.) There may still be some caveats that need to be addressed in order to make it work 100% seamlessly as a Firemonkey backend. More info here:

http://graphics32.org/news/newsgroups.php?article_id=11565