SVG or GDI+ in the LV UI

[viSci]

Just wondering, since we have some SVG afficianado's in the audience, if it is possible to use LV to dynamically creat SVG content and display within a .net container?  I can see that it is possible to place a .net picture control on the front panel but I think SVG would be much more elegant.  

 

A little ranting here...

 

I am a little frustrated that all LV programmers have for developing embedded custom 2D graphics is the very very very old 2D picture control.  The rest of the world has marvelous tools like WPF, SVG or even GDI+.  Yes, I know, as many have pointed out, that you can do anything with the 2D picture control and I think LV'ers get a kick out of how much they can force out of such primitive tools.  Wow, how did you get the picture control to do that nice anti-aliased display with z-ordering of emulated alpha channel bitmaps?

 

I think some people would be willing to pay for a nice 3rd party 2D  graphics toolset.

 

 

[ShaunR]

I think some people would be willing to pay for a nice 3rd party 2D  graphics toolset.

Bitman

[viSci]

Yeah Bitman is awesome but I don't think it really helps with anti-aliased display of 2D primitives like lines and arc's

[mje]

Yeah, the 2D picture control is definitely not aging well. At least it handles primitive shapes as op-codes so it is "vector like" so long as you don't go mutating the picture "string" to other formats.

[viSci]

Yeah the opcode thing is cute

 

http://lavag.org/files/file/26-picture-hacks/

 

but not sure it is anything useful. Reminds me of this crazy stuff to parse SVG into a LV Graph

 

http://drics.googlecode.com/svn/LabView/SVG/

 

I am really surprised no one (at least I have yet to find them) that has explored the .net PictureBox for use in LV.

It has tons of cool features.  I have been trying to use the API but so far have not gotten much to work yet.

[mje]

Truth be told I find the op-code based nature of the picture to control to be more of a burden when all I want to do is show the image in a picture control. Large pictures-- that is pictures with a large number of operations, not necessarily large pixel size-- display horribly slow in the picture control. Most of my applications involve generating an op-code picture string, then converting it to a bitmap and back to a picture string so the picture data only contains raster data. The raster data renders much quicker.

 

However the opcodes are great for the odd case when you want to play with zoom levels on the picture control as the opcode based picture strings maintain fidelity as you zoom in. Similarly if you want to export the image to vector enabled meta-formats like EMF.

[Rolf Kalbermatter]

Truth be told I find the op-code based nature of the picture to control to be more of a burden when all I want to do is show the image in a picture control. Large pictures-- that is pictures with a large number of operations, not necessarily large pixel size-- display horribly slow in the picture control. Most of my applications involve generating an op-code picture string, then converting it to a bitmap and back to a picture string so the picture data only contains raster data. The raster data renders much quicker.

 

However the opcodes are great for the odd case when you want to play with zoom levels on the picture control as the opcode based picture strings maintain fidelity as you zoom in. Similarly if you want to export the image to vector enabled meta-formats like EMF.

 

Actually most vector based formats are somehow build like the LabVIEW Picture Control stream. Not sure about SVG but WMF/EMF or the Macintosh PICT format are like that. Most likely the performance of the Picture Control comes partly during building of the picture stream with all those Append String nodes that creates a rather bad performance and then in the rendering because it is build on LabVIEW internal routines that then map more or likely less directly to the platform API. Also the fact that it is likely mapping into good old GDI instructions under Windows rather than going into a more performing interface like GDI+ or OpenGL. But GDI+ or OpenGL was not an option in LabVIEW 2.5 when this was invented and porting it later to use these new APIs would likely cause many compatibility issues that could introduce breaking issues to existing applications.

 

The 3D picture control (the built in one, not the ActiveX control) should be much better in terms of performance although it is not ideal for 2D vector based images but specifically meant for 3D visualization.

[viSci]

The 3D picture control is very cool and it does seem possible to create wrappers that would emulate basic 2D functionality while benefiting from such features as object hierarchies, support for transparency and anti-aliasing.  I have also been toying with the .net GDI+ picturebox, It is much more sophisticated than the native LV picture control and am surprised that there are little to no LV examples of its usage.  I have also heard a rumor of a LV->SVG toolset which could be used to turn an embedded browser into a rendering canvas.

Wait are you saying that a decision made way back in LV 2.5 has been the reason why LV 10 years later still does have GDI+ under the hood?

[Rolf Kalbermatter]

Wait are you saying that a decision made way back in LV 2.5 has been the reason why LV 10 years later still does have GDI+ under the hood?

 

Not GDI+ but GDI. And it's not 10 years later but 20 years later. But you have to consider the implications. Anything 2D based in LabVIEW is done using a 2D internal API that maps to whatever drawing primitive API is available on the platform. For MacOS that was Quickdraw (and probably still is, as rewriting the code to interface to Quartz (CoreGraphics) is anything but a trivial job, for Windows that was and is GDI, and for Unix systems that is X Windows.

 

All of them are the basic drawing APIs most applications are using even nowadays to perform UI drawing, if they don't only use standard system widgets and don't draw anything themselves. OpenGL is almost only used in applications with 3D output rendering, and GDI+ is by most applications only indirectly used since the .Net UI framework builds on that. There are very few applications that make actually directly use of any of the features that GDI+ offers. And DirectX is an API that is almost exclusively used by game engines if they don't want to have multiplatform support, otherwise they would likely go to OpenGL instead.

 

For most anything in most applications, the basic GDI, Quickdraw, Quartz and X Windows systems are actually more than fast enough and LabVIEW makes no real difference there. The only areas where it would benefit somewhat from a faster API are possibly graphs (although I would not expect a huge speed improvement there) and the 2D picture control. But you have to weight always the effort and the benefit, as well as the possible outfall because of incompatibilities. Rewriting the 2D graphic primitive system to take advantage of newer technologies just for the Picture Control would be way to costly, changing it for anything 2D related would not bring much benefit speed wise, but be a resource intense project and cause likely all kinds of problems in terms of many bugs introduced but also much more subtle issues, such as small but sometimes also more visible differences in the visual appearance of the entire UI rendering.

 

In short a lot of work for little visible benefit and with the likely chance to get criticisme for pixel to pixel inaccuracies in comparison to the previous implementation. Rewriting a perfectly working subsystem in an existing app, is always a very risky business and LabVIEW is no difference there. The Picture Control which is the only component in LabVIEW that would probably gain much from that is not a core component as it is only used by a few.

 

Now there might be a rewrite at some point especially when retina type displays get the new standard and it gets more and more important to have subpixel rendering inside the app. But LabVIEW isn't a prime candidate for that and the LabVIEW developers won't take on such a project just for fun and to be able to brag about it! Also retina type support under Windows isn't really ready yet and probably quite some time away on Unix.

[shoneill]

I've misused the 3D picture control as a 2D display area in the past.  Texture scaling is so much more efficient it's just nor funny any more.

 

 

Three separate 3D objects.  Upper is a simply Quad with texture applied, middle is another quad with a linearly interpolated and vertically copied texture and the bottom one is again a quad with simply texture applied.  It was a little tricky at first making sure the first and third objects had the same texture size as dispaly pixels (to prevent blending) but it worked quite well and was way way faster than anything equivalent in 2D.

 

Shane.

[shoneill]

Shane, did you attach the correct image?

 

Your description mostly matches the picture, but not quite as I see it. Is the upper the curve and the bottom the text, or should there be an upper?

 

Why did you need to texture the curve, surely the quad rotated so it was on its side would have done the same thing?

Yup, it's the correct image.

 

The curve (Upper 2/3rd of the picture is a single Quad with the curve applied as a texture (Generated using 2D picture controls BTW)

The middle part (The comour bar with varying intensities) was prohibitively expensive to redraw with traditional 2D picture control.  Therea re a fixed number of pixels on the detector (in this case it was 256) but the scaling and interpolation coupled with the vertical stretching of the colours was very time consuming on a 2D control.  With the 3D picture control it was lightning fast.  It was a simple input of 256 Colour values (which need to be modified for intensity) and OpenGL does the rest.

The botton part (The numbers) is, similarly to the upper part simply a Quad with a texture (which was again generated with the traditional 2D picture controls) applied.  Both the upper and lower parts were sufficiently fast to redraw with the 2D picture control (and subsequently applied to the 3D picture).  The middle part (The coloured part) was not.

 

Shane.

[shoneill]

I've spent quite some time investigating the functionality of the 3D picture and I question whether it's worth a "proper" OpenGL wrapper....

 

There's a LOT of undocumented but official (Yeah, the help sucks) functionality int he 3D picture control.  Did anyone know that you can share the geometry data between objects but still scale then individually?  This allows memory-efficient implementation of multiple copies of a single object for example.  Or even proper documentation of the different texturing formats available would be cool (I've already found out through trial and error).  Maybe they're all already in the help but for the life of me I could never find them....

 

Shane.