LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
tst

Add a zoom function (yes, I said zoom. So sue me)

Status: Completed

Now available in LabVIEW 2023 Q3

Add a slider on the toolbar which would allow changing the zoom level on the diagram. This should also be controllable more easily (for example, by using shift + mouse wheel scroll).

 

Personally, I want this less for zooming out and more for zooming in. It's sometimes convenient to have a larger display of a specific area.

 

I know some people feel that a zoom is a terrible idea because it will encourage people to create huge diagrams. Personally, I doubt that (since you can't work on zoomed out code and zooming out and in repeatedly isn't that convenient), but I don't mind if people do that. It's their code (as long as I don't have to work on it later).

If people really insist, this can also be prevented by setting the maximum value of the slider to 1, so that people can't zoom out, but I doubt this would have any value.

 

The zoom should snap to 1 when you get near it and should center on the mouse cursor.


___________________
Try to take over the world!
102 Comments
yenknip
Active Participant

Further from my last comment, the inbuilt windows zoom is slow to update itself, and infuriates me no end.

My perfect solution would be a floating window that follows the mouse and zooms the area underneath x2 or even x4

zoom.png

_____________________________
- Cheers, Ed
JÞB
Knight of NI
Yenkip-  a floating blow-up would be very distacting when wiring a conector pane!  Oh! my head hurts thinking of it when crossing the FP from controls to the connector pane.  the menu bar tansits alone  make me twitch to think of.

"Should be" isn't "Is" -Jay
JackDunaway
Trusted Enthusiast

Tansits?

 

Well, I agree, it would give me a headache too, but to each his own. I have seen people with poor eyesight using hover-over mag tools with ease, and they would not have it any other way. I would prefer a CTRL+Scroll for any type of zoom operation that would work for the whole panel, but my opinion doesn't matter as much here since I'm not the primary beneficiary of this Idea.

cmarquez
Member

Kudos on the ZOOM!  I'm getting blind from too much LV programming.

labview4steve
Member

yes - definately - this is one of my pet peaves when I work on my laptop when I'm away from the office. It is a proverbial pain the you know what. I'm only in my 30's and i struggle with tiny connectors and wires. This needs to be implemented immediatly.

Mr.Mike
NI Employee (retired)

So....I figure I ought to answer this since this conversation has gone on for a while and no one from NI has commented constructively (I'm looking at you Aristos Queue ;)).  I think the reason that no one at NI has given a clear answer is because the answer is disappointing and hard to explain.  My opinion (which sadly doesn't dictate the product's direction) is this: zoom will not happen any time soon.  I'm confident that this is not on anyone's short term radar.

 

LabVIEW is heavily reliant on raster graphics AKA bitmap images: this pixel is this color, that pixel is that color.  Raster graphics scale very poorly.  Whenever you see some image that's all "pixelated" that was a poorly scaled raster graphic.  If we did choose to scale the raster graphics, it would look horrible.

 

Programs which use text primarily and little graphics in their documents (text editors, Microsoft Office) are easy to scale because most fonts are vector based.  Vector based graphics scale because they're defined as lines and shapes in relation to each other, not a set of points on a grid.  When you have some programs that zoom with graphics (i.e. the grid in Microsoft Excel or most of PowerPoint), those graphics are redrawn just scaled up.

 

I don't think it's worth the time going into the extent to which LabVIEW uses raster graphics in the front panel and block diagram, but it's not a short story.  I'm sure I don't know all of it and I'm also sure that some of what I know is wrong.

 

Essentially the block diagram and front panel views are not sufficiently compartmentalized from the rest of the LabVIEW source code to make it easy or safe to replace and the potential cost is probably more than NI is willing spend given its payoff.  And that's not to say we don't like making our customers happy, just that we think there are other ways that investment can be spent which would make customers much happier.  (That's my opinion only.  It is not a statement by NI or any indication of what NI will or won't do).

-- Mike
wildcatherder
Active Participant

It is obviously a big step to go from bit-map to vector-based imaging.  However, users of all types of "smart" graphics programs now expect this functionality.  The Windows Magnifier is a poor substitute and National Instruments users should expect more than a defense that it would encourage ungainly large VIs.  The primary reason large VIs are ungainly is because of the difficulty in navigation.  A large VI can be just as well (or poorly) written as a collection of small ones.

 

I am concerned that the image drawing system in LabVIEW already appears to be strained when moving large chunks of the Block Diagram.  There is already a bug report about the program crashing with large moves.  Obviously another step of bit-map to vector and back again would use computational resources.  Consequently, the implementation should be user selectable, i.e. bit-map with no zoom  --  vector-based with zoom.  This only applies if the implementation would be keeping the bit-map format and using on-the-fly conversions for scaling (which would not look good).

 

The reason for zoom out (which would be a trivial addition once zoom in is implemented) is for ease of navigation.  One zooms out to view the "big picture", selects the new area of interest, then zooms in.  Navigating with the scroll bars is extremely tedious.

 

One way or another zoom has to be implemented.  We're going blind here.  🙂

crossrulz
Knight of NI

I'm fine with the zoom in.  But I still think the zoom out would be bad, mostly for the reason that that would encourage very large VIs.  Besides, there's already the Navigation Window (VIEW>>Navigation Window or Shift+Cntl+N) that is basically a zoom out.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
tst
Knight of NI Knight of NI
Knight of NI

Mike, the pixelation when zooming in really isn't an issue, as this is meant for ease-of-use, not for show (although, don't let that dissuade from considering changing the entire LV FP and BD display engine to something a bit more modern. I haven't worked much with WebLV, but if memory serves, it has both vector graphics and zoom. Of course, being a new program written from scratch in Silverlight, it has a number of advantages in that area).

 

That said, I can't comment on how dangerous it would be for LV to touch all that area. I can understand how places in the code would expect the click to be on a very specific pixel and how it would break if that was touched.

 

I can say that the Windows 7 magnifier is a lot better than the XP one and works as a floating window, exactly as requested by yenknip. I haven't used it so far, though, probably because it's too much of a hassle to remember to open it. I would prefer if this was inherent to the program, just like it is for Word, Firefox, Photoshop and any number of other programs.


___________________
Try to take over the world!
Mr.Mike
NI Employee (retired)

@wildcatherder wrote:
The Windows Magnifier is a poor substitute and National Instruments users should expect more than a defense that it would encourage ungainly large VIs.

Though NI promotes small block diagrams for code cleanliness reasons, we're not using it as a justification for not having zoom. 

 


@tst wrote:

 

Mike, the pixelation when zooming in really isn't an issue, as this is meant for ease-of-use, not for show (although, don't let that dissuade from considering changing the entire LV FP and BD display engine to something a bit more modern. I haven't worked much with WebLV, but if memory serves, it has both vector graphics and zoom. Of course, being a new program written from scratch in Silverlight, it has a number of advantages in that area).

 


Thanks for your input regarding the quality of the zoom.  And yes, "WebLV" or rather LabVIEW Web UI Builder (which I think is a more accurate name...it builds web interfaces to LabVIEW; it's not a web version of LabVIEW) uses vector graphics and has zoom and is shiny and new and fun to play with :).  (You use it for free here!).  However, there's not going to be any effort into copying that front panel/block diagram system back into LabVIEW.

I disagree though that the Windows 7 magnifier is usable for LabVIEW.  It blocks too much as a floating window

 

-- Mike