AggPas and BGRABitmap comparison

[Graeme]

Continuing from the original thread, but under a new topic name.

Another nice feature I like using in AggPas is hooking up multiple rendering pipelines (eg: TAgg2D as well) to the same render buffer, but each instance only has access to a certain region of the rendering buffer.

For multithreading?

Exactly, yes. But there are other uses too.

For example 6, here is how to do it with BGRABitmap.

And suddenly BGRABitmap usage also looks quite complex [or no different to AggPas]. At least it does for me - speaking as somebody that is not familiar with BGRABitmap.

Other useful AGG features are pixel buffer formats - AggPas already contains quite a few formats as standard though. It is quite easy to add new buffer layouts. eg: One could add a FPImage pixel buffer format where color channels are Word size instead of the more common Byte size.

From the name, I'm assuming BGRABitmap only supports pixel buffers in the BGRA32 format?

[circular]

And suddenly BGRABitmap usage also looks quite complex [or no different to AggPas]. At least it does for me - speaking as somebody that is not familiar with BGRABitmap.

Indeed, in this case it is similar. That's what I am saying, that you want to do something usual with BGRABitmap, it is simple, and if you want to do something a bit more special, you can do it, it becomes a bit more complicated, but that's possible. Now if something is used often, people can request that it would be integrated, that there would be a function that would do exactly that.

That's also why I am inviting you to actually write those classes that make life simpler so that people can use AggPas without too much thinking. Otherwise it is a steep learning curve and it is out of reach for many people.

Other useful AGG features are pixel buffer formats - AggPas already contains quite a few formats as standard though. It is quite easy to add new buffer layouts. eg: One could add a FPImage pixel buffer format where color channels are Word size instead of the more common Byte size.

From the name, I'm assuming BGRABitmap only supports pixel buffers in the BGRA32 format?

Yes. I am considering adding other pixel formats, but for now that's indeed BGRA or RGBA 32-bit. That's the bit I agreed with you as we started this conversation.

For me there are two advantages to AggPas, as I said from the start:
- it is faster on average for software rendering
- it has different pixel formats for the rendering buffers

There are two drawback:
- it is complicated, not readable, using a peculiar object model
- you need to add ten or twenty units to the uses clause for the simplest program and lots of initialization code

It is more or less equal to BGRABitmap regarding:
- quality of drawing
- doing specific things (with AggPas using the pipeline and with BGRABitmap using scanners, paths, arrays of points)

There are things that are not better but some ready-to-use features are in one library and not the other.

AggPas has some 2D transformation features for path and images that are not available in BGRABitmap and better SVG support
BGRABitmap has Phong shading, Foyd-Steinberg dithering and color number reduction, lots of ready-to-use filters, OpenGL 2D and 3D acceleration, lots of raster image formats including layered images

[Graeme]

- you need to add ten or twenty units to the uses clause for the simplest program and lots of initialization code

Then use the Agg2D object located in the agg_2D.pas unit for pure non-gui applications. Or use the TAgg2D class located in the Agg2D.pas (for use with fpGUI - Lazarus includes the equivalent for LCL).

http://www.crossgl.com/aggpas/documentation/index.html

Then you only need to include one unit and use a much simple API. You do sacrifice some of the more advanced AggPas features, but most seem happy with what it offers.

On a side note:
I'm also busy implementing LCD anti-aliased sub-pixel text rendering for AggPas. Developers will then be able to choose between the 256 grayscale or color anti-aliasing of text.

[circular]

There are indeed lots of functions in Agg2D. However I am thinking about not sacrificing anything.

I'm also busy implementing LCD anti-aliased sub-pixel text rendering for AggPas. Developers will then be able to choose between the 256 grayscale or color anti-aliasing of text.

I am curious, can you expand a bit on that?

[Akira1364]

In my opinion:

AggPas (and indeed Maxim Shemanarev's Anti-Grain Geometry C++ library which it was ported from) was never intended to be a standalone graphics library, but moreso a raw foundation on which one might build a graphics library. For day-to-day immediate use, it just doesn't have anywhere close to the overall capabilities and ease-of-use provided by BGRABitmap.

[Graeme]

it just doesn't have anywhere close to the overall capabilities and ease-of-use provided by BGRABitmap.

Capabilities? Have you actually ran all the demos included with AggPas? They are very impressive, fast and clearly show that AGG (and AggPas) is up to the task for some serious 2D graphics. No wonder that Haiku, OpenStreetMaps, MatPlot, Foxit Reader (PDF viewer) all use the AGG library.

Don't confuse "different" with not capable. As with anything programming related - it takes time to truly learn a framework you haven't used before.

[Akira1364]

it just doesn't have anywhere close to the overall capabilities and ease-of-use provided by BGRABitmap.

Capabilities? Have you actually ran all the demos included with AggPas? They are very impressive, fast and clearly show that AGG (and AggPas) is up to the task for some serious 2D graphics. No wonder that Haiku, OpenStreetMaps, MatPlot, Foxit Reader (PDF viewer) all use the AGG library.

Don't confuse "different" with not capable. As with anything programming related - it takes time to truly learn a framework you haven't used before.

For starters, all of the applications you listed are certainly written in C++ and use the original C++ version of the library. Secondly, yes, I have ran the demos, and experimented with AggPas rather extensively. Nothing it can do isn't something that can be done 90% of the time in less lines of code with BGRABitmap (or even with Graphics32, which I personally think is itself rather outdated.) It also does not provide any kind of library-native generic image class equivalent to a TBGRABitmap (which can load, contain, and modify pretty much any image file type you'd ever want to use with zero effort), which to me makes it immediately far less useful. Finally, it has no 3D capabilities at all, whereas BGRABitmap has an (increasingly) robust set of them. Honestly though I was not trying to pick a fight here, just stating my opinion! I think fpGUI is a very impressive project regardless of what graphics library you're using.

[fxc]

hi circular and thanks for the great BGRABitmap
indeed aggpas is faster than BGRABitmap , didn't you find where is the bottleneck ? , i my self tried but the source is extremely large, i lost  .
on the other hand BGRABitmap is easier and elegant than aggpas .

if i were you (i wish i had your knowledge ), i'd spend much time on optimization rather than adding new functionality .

[circular]

Hello fxc

Indeed I am wondering where is the bottleneck and I did try to look at the source code but I also got lost. I may try again, as AggPas is a source of inspiration regarding its speed.

I have been optimizing here and there, for example the fast blur and the polygon filling functions. Maybe I will go through AggPas examples and compare the speed of each of them and try to find what elements are slower.

@graeme: The point of Akira, as was my point as well, is not that you cannot do things with AggPas, rather than you can do things with very few lines of code. And that's what I have been aiming for in my work with BGRABitmap.

[Graeme]

For starters, all of the applications you listed are certainly written in C++ and use the original C++ version of the library.

Yes, and AggPas is an exact copy of AGG, but just in Object Pascal. If you compare any unit from AGG with the equivalent unit of AggPas, the code will match exactly, and even the unit names are identical. The same goes for the demos.

It also does not provide any kind of library-native generic image class equivalent to a TBGRABitmap (which can load, contain, and modify pretty much any image file type you'd ever want to use with zero effort)

You clearly don't understand AGG/AggPas then. It renders to any image buffer, which can even be something as simple as a byte array. It also supports many more pixel formats to what BGRABitmap can - in fact, BGRABitmap only supports BGRA (8-bit color channels) formats. Simply tell AGG/AggPas the image buffer it can use (most classes that represent an image gives you access to the raw image data) - LCL does, VCL does and fpGUI does. The TAgg2D class makes that a single method call - TAgg2D.Attach (bitmap, flip_y): boolean;

Finally, it has no 3D capabilities at all,

Well, considering that AGG/AggPas is a 2D graphics library by design, that makes perfect sense then. ;-) It never had a design goal to be a 3D graphics library. If you want a 3D graphics library, look elsewhere like at OpenGL or equivalents with hardware acceleration.

Regards,
  G.

[Graeme]

...you can do things with very few lines of code. And that's what I have been aiming for in my work with BGRABitmap.

And AGG's goal was not to create a "black box" effect. On that ground the designs are vastly different. BGRABitmap follows the classic design of supplying a Canvas like class that does everything (or almost everything). AGG's goal is to give you independent features that you can literally string together (customizable pipeline rendering engine) creating any unique combination you need for a specific task. Maybe the original AGG website can explain that design goal better than I do.

[circular]

I think you are putting it well Graeme about how AGG is structured.

By the way, if we do another graphic contest, you are invited to join. You may want to show us what you can do with AGG.

[circular]

About the examples we talked about and distorting the pen, with version 9.1 you can do it easily with BGRABitmap:

Code: Pascal  [Select][+][-]

1. uses BGRATransform, BGRAPath;
2.  
3. procedure TForm1.BGRAVirtualScreen1Redraw(Sender: TObject; Bitmap: TBGRABitmap);
4. var
5.   matrix: TAffineMatrix;
6.   path: TBGRAPath;
7. begin
8.     matrix := AffineMatrixIdentity;
9.     matrix *= AffineMatrixTranslation(Bitmap.Width div 2, Bitmap.Height div 2);
10.     matrix *= AffineMatrixScale(0.4,0.75);
11.     matrix *= AffineMatrixRotationDeg(35.0);
12.     matrix *= AffineMatrixTranslation(-Bitmap.Width div 2, -Bitmap.Height div 2);
13.  
14.     path := TBGRAPath.Create;
15.     path.moveTo(10, 10);
16.     path.lineTo(Bitmap.Width-10, 10);
17.     path.lineTo(Bitmap.Width-10, Bitmap.Height-10);
18.     path.lineTo(10, Bitmap.Height-10);
19.     path.lineTo(10, Bitmap.Height-20);
20.     path.bezierCurveTo(Bitmap.Width-20, Bitmap.Height-20,
21.                        Bitmap.Width-20, 20,
22.                        10, 20);
23.     path.closePath;
24.  
25.     Bitmap.Pen.JoinStyle := pjsMiter;
26.     Bitmap.Pen.StrokeMatrix := matrix;
27.  
28.     Bitmap.FillPath(path, matrix, BGRA(160,180,80));
29.     Bitmap.DrawPath(path, matrix, BGRA(120,100,0), 6);
30.  
31.     path.Free;
32. end;

You can switch between the two examples 5 and 6 by commenting out the line that sets the StrokeMatrix property.

I would still say it is not a "black box". Is AGG a "black box" for having the TAgg2D class? No because you can rewrite it using lower level functions. Same thing with BGRABitmap, you can rewrite the example above by computing explicitly the array of points, multiplying by the matrix, creating the polygon filler and calling the DrawShape procedure.

[Akira1364]

You clearly don't understand AGG/AggPas then. It renders to any image buffer, which can even be something as simple as a byte array. It also supports many more pixel formats to what BGRABitmap can - in fact, BGRABitmap only supports BGRA (8-bit color channels) formats. Simply tell AGG/AggPas the image buffer it can use (most classes that represent an image gives you access to the raw image data) - LCL does, VCL does and fpGUI does. The TAgg2D class makes that a single method call - TAgg2D.Attach (bitmap, flip_y): boolean;

I understand it. What you're describing isn't the same thing as what I was referring to. A TAgg2D is basically a canvas on steroids that can, as you said, attach itself and draw to buffers of arbitrary type. A TBGRABitmap is an actual image class that behaves like you would expect an image class to behave (i.e. with full SaveTo, LoadFrom functionality, e.t.c.) that works with pretty much every file format while also having three different canvases (CanvasBGRA, Canvas2D, and normal Canvas) built into it that can draw directly to its image data.

Well, considering that AGG/AggPas is a 2D graphics library by design, that makes perfect sense then. ;-) It never had a design goal to be a 3D graphics library. If you want a 3D graphics library, look elsewhere like at OpenGL or equivalents with hardware acceleration.

As near as I can tell, BGRABitmap didn't originally set out with any 3D aspirations either, and it's still by and large a 2D-focused library. The point is though that is has 3D capabilities now.

[circular]

I suppose it would be possible to add some 3D features to AggPas as it already has perspective transform. So by plugging this with an algorithm to compute the 2D points of a 3D scene, that would do.