LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

BUG: Performance in zoomed mode in IDE

When zoomed in/out (even small amounts) the IDE performance TANKS! 

Reproduce:

- Open a block diagram

- Select and move some things or wires to get a performance reference

- Zoom in a little e.g. 120%

- Select and move some things, feel the difference!

- Reset zoom to 100% (ctrl+0)

- Select and move some things

 

 

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 1 of 32
(665 Views)

I simply don't zoom and I don't like the current implementation, especially what it does to fonts.

 

All they should have done is keep the FP/BD 1:1 in memory and add a thin layer that zooms the original for display and remaps mouse inputs and even adds antialiasing.

 

Even Chrome can do zoom in/out  on the fly keeping everything proportional.

(might use the GPU, but I am not sure).

 

altenbach_0-1715617132384.png

 

Message 2 of 32
(636 Views)

This is very subjective. Zoom is a bug by design like global variables.

Message 3 of 32
(611 Views)

Going forward, zoom is a must, e.g. once we get 10000dpi monitors. 😄

Message 4 of 32
(608 Views)

@Yamaeda wrote:

When zoomed in/out (even small amounts) the IDE performance TANKS! 

Reproduce:

- Open a block diagram

- Select and move some things or wires to get a performance reference

- Zoom in a little e.g. 120%

- Select and move some things, feel the difference!

- Reset zoom to 100% (ctrl+0)

- Select and move some things


Yes, I agree that in "zoomed" mode everything goes slowly, but I'll be very careful with "bug" term, because in the fact this is "performance issue" rather than "bug". The pure "Bug" is something different. Obviously for zoomed mode the development environment needs a little bit more resources, depends on internal implementation. The best "zooming" can be achieved (on Windows) with C#/WPF, where we have zoom nearly "for free", works well and hardware-accelerated (I guess). And the attempt was done, called "LabVIEW NXG", based on .net/WPF, which is failed, but the zoom option was really functional, because everything was a vectors-based. Classic LabVIEW written in C++ itself contains lot of "legacy" part, related to bitmap/GDI based graphics, therefore some penalties are here.

 

Here is another important part, which is closely related to zooming - HighDPI support. Few years ago I have had DELL laptop with 15 inch 4K display (and touch-screen!). It was brilliant vibrant screen, but for LabVIEW completely useless, moreover, it was very painful to work with such unsharp appearance. And in 1:1 mode everything was extremely small. After year of such "work" I gave this to my daughter, she is very happy. There are some discussion about real needs 4K on 15", but in my opinion this is "must have", because everything is so sharp, especially text appearance, close to 300 dpi resolution on monitor is really makes sense, also for my old eyes. But again, zoomed or not, LabVIEW looks weird on such monitor (vote for idea "Make LabVIEW DPI aware to support high DPI screens and Windows scaling - Non blurry text and graphic...").

 

Personally I using zoomed mode very rarely, but sometimes it is useful, especially if you have lot of wires, and attempt to connect these to 5x5 or 6x6  Connector pane (rare, but sometimes happened). Or zoom out for large diagrams. Also for control zoomed mode could be very useful if working at "pixel level" for fine positioning of the parts and decorations, but not implemented yet at all, here are lot of Ideas: 1, 2, 3.

Message 5 of 32
(555 Views)

@Andrey_Dmitriev wrote:

The best "zooming" can be achieved (on Windows) with C#/WPF, where we have zoom nearly "for free", works well and hardware-accelerated (I guess). And the attempt was done, called "LabVIEW NXG", based on .net/WPF, which is failed, but the zoom option was really functional, because everything was a vectors-based. Classic LabVIEW written in C++ itself contains lot of "legacy" part, related to bitmap/GDI based graphics, therefore some penalties are here.

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. The big problem is just that the coordinate system is in pixels just as GDI itself is. This was pretty much unavoidable as Windows in those days had nothing else. Mac was slightly better since Quickdraw had a less monitor centric view of the graphic output, NextStep would have been phenomenal since every graphic output device was a Postscript device with a virtual coordinate system with whatever resolution the current application wants. There still can be issues with font scaling since fonts typically do not scale very well in arbitrary steps. In Postscript this is not as visible since the fonts itself are defined as vector objects that can have their own virtual coordinate system that Postscript then maps into the overall coordinates. But Windows fonts are not exactly like that despite using the almost exactly same True Type File format that the Mac used, which was again an adaption and simplification of Postscript fonts.

 

WPF output for LabVIEW Classic is indeed almost an impossibility, way to many things in LabVIEW are assuming pixels rather than a virtual coordinate system. It's the pixel based view that makes it all so complicated, not the fact that LabVIEW doesn't do vectors, because in reality it does it very much when doing its graphics output. Use of WPF would also be a very "good" way into Windows only support for LabVIEW, so not really that desirable either.

 

The current zoom implementation may have some performance improvement leeway, but it may be also one of those features where the developers will eventually find out that they gave in to easily into the pressure to implement it, as supporting and maintaining it costs a lot of resources but the actual implementation simply falls short of user expectations. In that light the original refusal to implement it may have been not that a bad decision.

Rolf Kalbermatter
My Blog
Message 6 of 32
(545 Views)

@Andrey_Dmitriev wrote:


Yes, I agree that in "zoomed" mode everything goes slowly, but I'll be very careful with "bug" term, because in the fact this is "performance issue" rather than "bug". The pure "Bug" is something different. 


If the goal of the zoom feature is to be able to work in that mode, then it is a bug, because it was unworkable. 🙂

The problem with "just" calling it a performance issue is that it's easily overlooked compared to "real" bugs.

 

This was kind of a random find. As i'm not familiar with 2023 yet i ofcourse managed to zoom when i wanted to scroll a case but wanted to clean up some wires while i was zoomed in, that's how i found it.

Yes, as 4k (should really be called 2k or 8MP) and 8k on the way the zoom feature is a must and it must be more than just a "zoom in to look and don't touch". (I guess the last part aims more to @altenbachs "don't work zoomed in")

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 7 of 32
(542 Views)

Additional information: it's when i move stuff with the arrow keys, the mouse seems to work fine.

All movements in the clip is made by simply holding shift+arrow keys. 

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 8 of 32
(524 Views)

@Yamaeda wrote:

@Andrey_Dmitriev wrote:


Yes, I agree that in "zoomed" mode everything goes slowly, but I'll be very careful with "bug" term, because in the fact this is "performance issue" rather than "bug". The pure "Bug" is something different. 


If the goal of the zoom feature is to be able to work in that mode, then it is a bug, because it was unworkable. 🙂

The problem with "just" calling it a performance issue is that it's easily overlooked compared to "real" bugs.

 


"Unworkable" still not a crisp and clear bug definition.

In my particular case it work acceptable well. Yes, some minor delays (from click to movement) are here, but fully "workable":

zoom2.gif

Also with larger BDs almost the same.

This is my hardware — 8 cores Intel Xeon W-2245 (HT enabled) + NVIDIA Quadro RTX4000:

Screenshot 2024-05-14 12.27.56.png

Windows 10 22H2.

May you have issues with your Hardware/Software config?

0 Kudos
Message 9 of 32
(508 Views)

@Andrey_Dmitriev wrote:


"Unworkable" still not a crisp and clear bug definition.

In my particular case it work acceptable well. Yes, some minor delays (from click to movement) are here, but fully "workable":

 

Also with larger BDs almost the same.

This is my hardware — 8 cores Intel Xeon W-2245 (HT enabled) + NVIDIA Quadro RTX4000:

 

Windows 10 22H2.

May you have issues with your Hardware/Software config?


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)

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

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 10 of 32
(498 Views)