LabVIEW
LabVIEW Starves CPU core when zoom factor of a picture indicator is changed through property nodes.
As a first step, attach a simplified VI that demonstrates the problem.
How big is the "map" (in pixels)? What are the zoom factors you are trying to use? How big is the picture indicator?
If you are zooming with a slider and a value change event, how is the event queue configured? (see also)
I'm guessing that, because LabVIEW uses unaccelerated graphics to draw stuff, resizing is done on the CPU. Further following this rabbit wherever it goes, I would further assume that, since it is front panel related, it has to occur in the UI thread. Lots of guesses, and maybe leaning a bit more towards "wild" than "educated".
Unless you do a "save for previous" (2020 or below), I won't be able to look at your code for a while.
@NoumanFaheem wrote:
I have also attached the screenshot that shows the logical core being starved while zooming.
as Billiko said, this conduct is pretty likely due to the UI thread root loop:
https://www.genuen.com/blog/the-ui-thread-root-loop-and-labview-what-you-need-to-know/
@NoumanFaheem wrote:
To answer your questions the image is 895x895 pixels,
this appears to be a reasonable size, but please attach again saved in Labview 2020
you might try to enable/disable Smooth Updates:
moreover, the zoom property node appears to switch from resizing (with interpolation) to resizing (without interpolation) when some conditions are met (if smooth updates are enabled)
| with interpolation | without |
 |
 |
how to reproduce:
https://forums.ni.com/t5/Example-Code/Conway-s-Game-of-Life-Simulation/ta-p/3521032
if you need to zoom into your picture, you might consider to resampling instead of resizing
@NoumanFaheem wrote:
I am zooming in using mouse wheel event, the queue size is configured to be 5.
You should definitely set that to 1. There is absolutely no need to process any zoom value except the last one seen.
Events for changes of "analog style" operations (slider change, mouse scroll, cursor move, etc.) can queue up a huge number of events, so if the queue is set to 5, it will process the last five values in order when the movement ends. the first four of those are a complete waste!
For illustration, have a look at my ancient example (i.e. before the event queue configuration was available) and set the queue size of the middle event to 1 or 5 and compare.
@NoumanFaheem wrote:
Edit: The image generated in the VI is a simple square that's why the issue might not be prominent but when checked with real map data after pasting it onto the picture indicator I was able to reproduce the issue in this simplified VI as well.
Well, then attach the code with the map data! Is the "map" just a "image" or a huge collection of lines and other drawing objects?
In your example, you still lock the panel and don't limit the queue size. So please change that! I think you can also simplify the event case to make it easier to read. There is no reason to hide two identical property nodes in the two cases of a case structure.
I would also recommend to keep the shift register as an integer (e.g. 2x the zoom factor), and multiply it by 0.5 for the property node. This will avoid accumulation of floating point errors. You probably also want to coerce it to 1 and above in that case (a zoom factor of negative or zero seems unreasonable).
Why not do it exponential (half or double the zoom factor with each step, for example.)
( ... and please don't maximize front panel and diagram to the screen. That's extremely annoying)
