LabVIEW
BUG: Performance in zoomed mode in IDE
@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. 🙂
@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:
Around 120x140 cm artwork. Slightly blurry, its from 2002 ;).
@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
My quick test shows that BD still +/- 32K Pixels (totally 65K) wide:
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).
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. 😀
@Andrey_Dmitriev wrote:
Alternate way:
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. 😄
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, 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...)
