LabVIEW Graph Anti-Aliasing

[mje]

I'm looking to do some line drawing in the picture controls which frankly have to be anti-aliased. Really basic stuff that can be entirely software based. Does anyone know if the routines LabVIEW uses to draw lines in the graph/chart controls are exposed and can be re-used in any way?

 

I'm not against implementing something like the Wu algorithm myself, but clearly LabVIEW has already implemented something...

[ShaunR]

I'm looking to do some line drawing in the picture controls which frankly have to be anti-aliased. Really basic stuff that can be entirely software based. Does anyone know if the routines LabVIEW uses to draw lines in the graph/chart controls are exposed and can be re-used in any way?

 

I'm not against implementing something like the Wu algorithm myself, but clearly LabVIEW has already implemented something...

 

The scene object has anti-aliasing which is used in the 3D Graph Controls. Create a scene object and select "Specials>Anti-aliasing"

[viSci]

Been down this road and after fighting with the 3D graph and 2D picture control I became dismayed at LV's lack of modern 2D graphics with basic features such as anti-aliasing and the ability to define a hierarchy of graphic objects.  I was hoping someone would have tried to bring some SVG action in LV but instead had to settle for .net which is actually pretty nice.  I spent about 2 solid weeks wrapping .net graphics and produced some very nice anti-aliased radar type graphics. If interested I will try to wrap up my .net libraries and post in the CR. In the meantime you can see some of the results in my portfolio at www.viScience.com (Avionics 1553 Simulator)

[mje]

Good suggestions both of you. I have a whole set of internal libraries I'm using for 2D picture elements in this application, so I'd rather not make the switch to .NET or 3D just yet. That said this may be the last time I use the native 2D picture routines for any serious work.

 

I threw this together this morning as a proof:

 

The performance is as expected, hideously slow when it comes time to flatten the result (do not try to render the raw op-code string). As a result it's a literal interpretation of the Wu algorithm as described at wikipedia since all the optimization in the world won't change how slow it is to render op-code based dots in LabVIEW.

 

This is just a proof of concept, at this stage I'm happy enough to say it can be done and defer the implementation until later. Still needs color, line width, and ditching of the op-codes in favor of a raster buffer which should improve things by at least an order of magnitude.

 

Example code is LV2013, public domain.

Wu.zip

[ShaunR]

Good suggestions both of you. I have a whole set of internal libraries I'm using for 2D picture elements in this application, so I'd rather not make the switch to .NET or 3D just yet. That said this may be the last time I use the native 2D picture routines for any serious work.

 

I threw this together this morning as a proof:

Wu.png

 

The performance is as expected, hideously slow when it comes time to flatten the result (do not try to render the raw op-code string). As a result it's a literal interpretation of the Wu algorithm as described at wikipedia since all the optimization in the world won't change how slow it is to render op-code based dots in LabVIEW.

 

This is just a proof of concept, at this stage I'm happy enough to say it can be done and defer the implementation until later. Still needs color, line width, and ditching of the op-codes in favor of a raster buffer which should improve things by at least an order of magnitude.

 

Example code is LV2013, public domain.

Maybe create it as a plugin filter for Bitman. I always found Vugies Bitman is far superior in rendering performance for anything I do in 2D.

[viSci]

If you ever think of taking a dip into .net drawing here is some example code (LV2013) to get you started...

Forgot to mention that the example drawing vi is in the Test Folder

AntiAliased Drawing.zip