LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

BUG: Performance in zoomed mode in IDE


@Yamaeda wrote:

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!


That's the game changer (it wasn't present on your screen's recording) . Now I can confirm that the zoomed mode is almost useless when the navigation window is opened, also in LV2024Q1 64-bit as well. This can be considered a bug because it's more than just a performance issue, and without this window, it works much better. For the last 20 years, I've used the Navigation Window maybe two or three times. When the diagram gets larger, I usually refactor it to fit into one screen (at least on my 30-inch monitor).

Message 21 of 32
(16,675 Views)

@Andrey_Dmitriev wrote:

 For the last 20 years, I've used the Navigation Window maybe two or three times. When the diagram gets larger, I usually refactor it to fit into one screen (at least on my 30-inch monitor).

I don't use it in my everyday coding, but when opening Forum VIs it can be handy to see how bad/big it is and jump around. 🙂

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 22 of 32
(16,669 Views)

@Yamaeda wrote:

@Andrey_Dmitriev wrote:

 For the last 20 years, I've used the Navigation Window maybe two or three times. When the diagram gets larger, I usually refactor it to fit into one screen (at least on my 30-inch monitor).

I don't use it in my everyday coding, but when opening Forum VIs it can be handy to see how bad/big it is and jump around. 🙂


Alternate way:

BD.jpg

Around 120x140 cm artwork. Slightly blurry, its from 2002 ;).

Message 23 of 32
(16,659 Views)

@rolfk wrote:
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.

Hmmm, never heard that, but that would be great. Can you point me to a release note to back up that statement?

 

FYI, NI still has the following article, updated less than a year ago. 😮

 

Maximum Size for LabVIEW Front Panel and Block Diagram 

 

 

Message 24 of 32
(16,624 Views)

My quick test shows that BD still +/- 32K Pixels (totally 65K) wide:

Screen.gif

And I can't create more objects on the left and right sides (and during creating this BD I've got lot of funny visual effects).

Message 25 of 32
(16,615 Views)

I seem to have remembered something wrong. The VI coordinates still seems an i16 but the absolute screen coordinates is an i32.

 

Not that I ever felt like getting rilled up about the i16 limit for Vi diagrams and even less about frontpanels. Anyone creating such VIs should be forbidden to use LabVIEW. 😀

Rolf Kalbermatter
My Blog
0 Kudos
Message 26 of 32
(16,601 Views)

@Andrey_Dmitriev wrote:


Alternate way:

BD.jpg


LOL! Yeah i'm not doing that with every forum post! But i have done it a project when they wanted the code printed for review. 😄

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 27 of 32
(16,589 Views)

Some more information:

 

I increased the Navigation window, and it's size doesn't affect anything (noticable). However it allowed me to see something i haven't noticed before.

 

It works well when moving stuff with the mouse, and that's because the Navigation window doesn't update.

 

Moving with keys it sends an update for each step, and they even gets queued up as you, when it's slow, can see it do 2-3 updates after you stopped moving. It should be a lossy queue/event, only the last update is interesting.

 

So i did a simple "Navigation windows emulator" which uses the Get BD Image Scaled (or Front panel) and the Front panel grabs and scales an image in 5ms(!), the Block diagram on 100% takes 20ms (on this diagram) and with 150% scaling it takes 1900ms!!! On 200% it's a swift 3693ms!!!

 

Something is very broken with that function!

 

Yamaeda_0-1715875161138.png

 

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

Qestit Systems
Certified-LabVIEW-Developer
Message 28 of 32
(16,557 Views)

Yamaeda, I took the liberty of pasting your post from the annual bug thread here:

"The Zoom + navigation issue now has a Bug#: 2752615"

 

(the annual bug thread rule is one post per bug...)

Certified LabVIEW Architect
Message 29 of 32
(15,952 Views)

@thols Thanks, i forgot to update this thread. 🙂

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 30 of 32
(15,947 Views)