LabVIEW
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.
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>
@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?
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.
@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 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):
And when zoomed to 150% (175 is not available), then still good (some blur on the wires patterns, but icons just great):
Even look at huge 400%:
Now LabVIEW Classic, zoomed to 150%:
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:
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...
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. 😁
@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.
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!
