How do you increase performance for clients?

Hello everyone. Does anyone have any tips that will inform me on how to speed up loading screens and increasing display performance? Expression and indirect addressing objects seems like it takes forever to load and I am staring at a screen with error overlays. It looks pretty bad as you navigate from page to page. TIA!

Please reference this old thread.

Vision or Perspective?

In general, though:

  1. Minimize the amount of data that must travel between gateway and client.

  2. Minimize the amount of duplicate data repeatedly sucked out of your database (caching, etc).

  3. Minimize the amount of duplicate calculations done for multiple points of use (less important in Vision clients).


@pturmel’s points address improving performance. If Perspective, this method makes things look a lot better during navigation by hiding the invalid states while waiting for data to arrive:

Hey guys, thanks for the responses. I am using Vision. Will vision never look as good as perspective in terms of the error overlays then? I barely have any data traveling between the gateway and client, so I don’t think there is much to minimize.

It might help if you can provide some screenshots or video examples of the screens and slow loading you’re dealing with.

1 Like

A few things to note, don’t use UDT parameters, many threads on this, here is one:

Also, I gave up on overlays. Even on the fastest window, I would always get flickering of the overlays. I turned them off during project load, I think it was system.tag.setOverlaysEnabled(0)


One method is to reduce the number of individual bindings that exist on a single page and package tags that are similar (and make sense to be put together) into a dataset and then make the binding the client uses to the dataset rather than each individual tag. Our architect compares this to moving sand with a bucket rather than one grain at a time.

No idea if this can help in your case, but it is something we use often.



Ewww! Just no.

{ I would expect that technique to have negative performance. The gateway collects tag changes that it knows a Vision client wants and delivers them in bulk at the client’s poll rate. Delivering an entire dataset when not all elements change would significantly increase traffic. }


Since I received a “Ewww!” on my post I’ll add further qualifications to prevent being misunderstood.

A place we would use the dataset method would be on a screen that allows for viewing of all PLC I/O. In that case there can be 10k’s of tags and the most practical way to let the user see the state of any I/O point they want is with a dataset.

In any case, we would use it in places where the main source of consumption on the screen uses a table.

If data is not consumed using a table, other methods are probably better.


Thanks everyone. Is the overlay just something you have to deal with in ignition? I got that impression from other posts as well. Here is a video of some of the overlay lags:
Ignition Overlays

We’ve dealt with this in Vision by delaying display (cover it with some form of loading overlay) for a bit to give time for bound data to arrive. This accomplished what we now use a delayed fade-in transition in Perspective for.

1 Like

I think it depends on who you ask. IA has released fixes over time that was supposed to solve this, at least that is how they were advertised. But, in my experience none of the fixes actually fixed the overlay problem. As I mentioned earlier, I dealt with them by turning them off. I like the idea of having overlays, but not like how they currently behave.


Though I haven’t done this, turning off overlays for a few seconds on page load and then re-enabling them so configuration errors (as opposed to delayed data arrival) are shown might be a good solution.

1 Like

Not sure what you mean here, but I like the thought of delaying the display. I will most likely try that as well, thank you.

@jlandwerlen I made a button that turns off the overlays after I read your comment above, so thank you. Though, with a product of this caliber I feel like this shouldn’t be an issue to where we have to turn them off. Feels like a dirty fix on our end and we lose functionality because of it. Every screen has at least some overlays, making transitions between windows look pretty terrible at times.

I agree with the sentiment that the overlays in v8 are noticeably more annoying than in v7.

I can’t say that windows actually load any slower, but the visible overlay thrashing on window changes definitely make it feel slower.

@bmusson Agreed. And its happening on a standard template I am creating, before a large amount of tags even get put into the program. I’m scared to see how it looks when this HMI will actually have an assembly line being displayed on it.

I’m referring to a Perspective solution noted above before I realized this was for Vision:

In Vision applications, we cover up the screen with a loading layer that’s visible for a bit on page load and then hidden by a script. We use a script like this in window visionWindowOpened event so we don’t need to remember to save the window with loading mask visible in Designer:

loadingMask = system.gui.getParentWindow(event).getComponentForPath('Root Container.loadingMask')
loadingMask.visible = True

And a script like this on the loadingMask component that covers everything else during load:

if event.propertyName == 'componentRunning' and event.newValue:
	# Hide this loading mask when loading complete and this layer's (actually a group--groups used for layers) background is running.
	def hideMask():
		event.source.visible = False
	system.util.invokeLater(hideMask, 0)
1 Like

If that works, it is far better than to just leave them off. I never tried your approach, curious how well it would work.

@witman Thanks for that detailed response! I will look into this. Cheers.

You bet. You may need to increase delay milliseconds (“0” on last line of second script) to fully skip overlays).