LabVIEW
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
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).
@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.
@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")
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.
@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":
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?
@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)
