LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

BUG: Performance in zoomed mode in IDE


@Yamaeda wrote:


Now move the items with shift+arrow keys. 🙂 It seems to work well with mouse movement for me also, except when hitting borders with autogrow (which i know some disables)


No, still unable to reproduce. Also with arrow keys with or without Ctrl and when hitting border, growing as expected.

zoom4.gif

 

What is real bug is the crash after using Zoom, but this occurred sporadically:

<DEBUG_OUTPUT>
14.05.2024 13:11:44.603
DWarnInternal 0x1F1445DA: Wiring insanity found and fixed in WireTable::SanityCheck().  Wiretable had an unreachable joint. UID:1956
source\heapobjs\Wire.cpp(227) : DWarnInternal 0x1F1445DA: Wiring insanity found and fixed in WireTable::SanityCheck().  Wiretable had an unreachable joint. UID:1956
[ExecSys:0; NOT InExec]minidump id: da6f4522-32f2-4654-bcbe-a294e370c404

</DEBUG_OUTPUT>
0 Kudos
Message 11 of 32
(397 Views)

@Andrey_Dmitriev wrote:

@Yamaeda wrote:


Now move the items with shift+arrow keys. 🙂 It seems to work well with mouse movement for me also, except when hitting borders with autogrow (which i know some disables)


No, still unable to reproduce. Also with arrow keys with or without Ctrl and when hitting border, growing as expected.

 

 


Are you on 2024? I'm on 2023 Q3. Did you see my clip and how big difference it was?

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 12 of 32
(393 Views)

New information!

 

I have an nVidia card in my laptop, so i used the Control panel to force LV to use the nVidia instead of the default choice (which i assume is the integrated card) and it works a lot better(!) but still a performance hit. Still, it doesn't explain how/why it should be _so_ much slower.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 13 of 32
(388 Views)

For reference it was this VI from a previous thread i noticed it in.

 

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 14 of 32
(384 Views)

@Yamaeda wrote:

For reference it was this VI from a previous thread i noticed it in.

 


Still not soo bad for me. Video in attachment. In reality it moves a little bit more "smoothly" than recorded.

LabVIEW2023Q3, checked both 32-bit and 64-bit. It looks like 32-bit is slightly slower, bit not significant.

Me annoying the strings — the length changed depends on zoom, also borders of constants are "doubled" at some zoom factors, and the text is not centered, etc, not very accurate at all.

0 Kudos
Message 15 of 32
(338 Views)

@rolfk wrote:
Actually the way LabVIEW draws its controls is not pixel by pixel but through Windows GDI calls drawing lines and arcs and text. In a way it is already vector based.

I guess my point was that the final product is pixel based and can be mapped into an internal virtual screen equally well, to be scaled for the screen by efficient algorithms, even involving the GPU.

 

Here's how the diagram would look at various zoom factors using Chrome scaling (Code image from my post here).

 

(You can try with any other zoom factor available. Always looks great. Same could be done for the front panel)

 

altenbach_0-1715710140044.png

 

 

 

 

 

0 Kudos
Message 16 of 32
(322 Views)

@altenbach wrote:

@rolfk wrote:
Actually the way LabVIEW draws its controls is not pixel by pixel but through Windows GDI calls drawing lines and arcs and text. In a way it is already vector based.

I guess my point was that the final product is pixel based and can be mapped into an internal virtual screen equally well, to be scaled for the screen by efficient algorithms, even involving the GPU.

 

Here's how the diagram would look at various zoom factors using Chrome scaling (Code image from my post here).

 

(You can try with any other zoom factor available. Always looks great.


 

I will not say, that it looks great in chrome. Yes, technically correct, but its blurry as expected from pure bitmap resampled to 175%.

 

The statement that "LabVIEW Classic will continue to be bitmap-based graphics" is quote from Darren Nattinger.

 

Anyway, how it looks in LabVIEW NXG at 1:1 (I will not perform too much cleanup):

Screenshot 2024-05-15 06.48.16 (N XG1).png

And when zoomed to 150% (175 is not available), then still good (some blur on the wires patterns, but icons just great):

Screenshot 2024-05-15 06.49.30 ( NX G ) .png

Even look at huge 400%:

 

Screenshot 2024-05-15 06.50.13 (NXG ) .png

Now LabVIEW Classic, zoomed to 150%:

Screenshot 2024-05-15 06.56.28 (LV).png

Some icons are blurry, some not, pixel errors and lot of visual defects

Maximal zoom 250%: and now blue borders on constants "duplicated" on random edges etc:

Screenshot 2024-05-15 06.57.26 (LV250).png

So, partially its pure bitmaps rendering, resampled for zoom with poor aliazing (just take a look at "N" on the for loops). For me every pixel matter.

To be honest, this is not what I expect from the software at price € 4.350,00 per year...

 

0 Kudos
Message 17 of 32
(294 Views)

There is some reasonable suspicion that the bad performance may be system related considering the reaction from other people that they can't really reproduce the bad performance.

 

Have you already tried to check if there are newer graphics and chipset drivers for your system? There may not be or they won't fix that, but such sort of performance bugs in system drivers are even after 40 years of PC not very uncommon. 😁

Rolf Kalbermatter
My Blog
0 Kudos
Message 18 of 32
(281 Views)

@Andrey_Dmitriev wrote:

The statement that "LabVIEW Classic will continue to be bitmap-based graphics" is quote from Darren Nattinger.


I think that needs some more context and/or clarification. Yes the subVI icon is pure bitmap based and probably never will be anything else (In NXG it was supposedly vector based). The LabVIEW diagram and front panel is however anything but bitmap based unless you paste in some bitmaps into controls or the front panel or diagram. The coordinate system is however pixel based and ingrained in LabVIEW pretty much everywhere. They did originally have even 16 bit coordinates, which could really hose up your LabVIEW diagram if you happened to create one of those 20 screen wide diagrams. They eventually increased that to 32 bit coordinates in most areas to also allow for the increased coordinate space that multi monitor systems could end up needing.

 

As to zooming, LabVIEW most likely uses off-screen device contexts to render the diagram and front panel, scale it and then blit it onto the screen. That has of course some overhead and GDI scaling in such a way indeed causes a round trip through a bitmap. The possible interpolations that can be chosen are rather limited too. They are not really optimized for line drawing graphics, which LabVIEW is except for the icon. I'm sure Chrome does it through bitmaps too, but it may have its own internal rendering system rather than relying completely on GDI, WPF or X Windows extensions.

Rolf Kalbermatter
My Blog
0 Kudos
Message 19 of 32
(278 Views)

Eureka!

 

It's the Navigation window that causes the delay! (which i typically open to see how bad a big vi is) ~150% zoom and navigation window open and it takes 4s per step!

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 20 of 32
(271 Views)