[IGN-8155]Gradient Paints - Big Performance Hit on MacOS

I was trying to troubleshoot why a few of our projects have terrible performance in the Designer for some of our screens. The issue seemed to be limited to MacOS (video below) - although we didn't test Linux. The same windows have no performance issues when opened in the Designer running on Windows OS. After a lot of trial and error I tracked it down to the gradient fill paints in the equipment objects that seem to be the culprit. When I set them to a solid color, the performance goes back to what I would expect. The other interesting aspect here is that the same window works fine in a client running on MacOS - it is completely limited to the Designer.

I generated a quick example to show the performance hit with and without gradients. I went a little overboard with the number of objects to show how severe it is, but honestly the number of paths I have in there isn't that far off from many of the symbol factory objects - especially if you have 20 plus symbol factory components in the same window. I've replicated this same behavior in versions 8.0.x, 8.1.25, and 8.1.28. I do NOT have the same issue with a 7.9.x gateway even though many of the project windows on that gateway have more gradients than the windows in the 8.x projects. I have replicated this behavior on a couple versions of MacOS (13.4.1(c), I don't have the other one handy...). They are both ARM based Macs. Attached a bare-bones Vision window if interested.

Gradient_Issue_On_MacOS.zip (5.9 KB)

Wow, that is really bad. Consider me successfully nerd sniped.

I can pretty immediately tell it's slow in native code, which makes this more interesting...


Maybe it’s better in Java 17?


Wouldn't you expect the performance to be terrible in the Designer and Client, not just the Designer? I'm wayyyy out of my wheelhouse here so I'm honestly curious!

Yeah, that’s my first instinct. But there’s other stuff on the screen with the Designer, who knows what kind of weird rendering dependencies might be at play. :man_shrugging:

1 Like

I thought it might be an interesting one since it only impacts the Designer!

...yea...to the point where I won't even work on the screens. Have the others on the team who are using Windows machines take care of them. Good kick in the butt though to start transitioning those screens to High Performance HMI designs :laughing: :sob:

Running the Designer on Java 17 helps a bit, but it's still pretty unusable.

You might need to opt in with -Dsun.java2d.metal=true

1 Like

Well, I broke the XCode profiler. Specifically enabling Metal definitely helped, but was still not usable. But I can't say for sure it was even running or not without peeking at the trace. I'll have to pick this up another time.


You seem to have connected the wrong dots and not drawn the primary conclusion here, which is, better to stay away from Mac :smiley:


Haha, I knew you were going to have that response - too easy! The less I touch that pile of :poop: Windows laptop I have, the happier I am! And I used to only use Windows. Maybe some day I'll smarten up and switch to Linux, but probably not :sweat_smile:


I don't think i'll ever get there. Raspbian Debian scared me off haha. Everything is so damn hard to do


I wonder if it's a jxbrowser thing? can you try in Perspective Workstation and see if it's slow there?

Well, that's not surprising. Cut to the bone to run on an RPi.

Try Kubuntu. Or OpenSUSE. Or a KDE spin of Fedora.

This is all Vision/Swing - no ability to blame it on web tech, I'm afraid :joy:

Also, fwiw, this performance hit seems to also impact Intel-based Macs, so we can probably take out the Rosetta 2 possibilities here.

Oh right, I didn't see the tag haha, whoops

Alright, well, XCode finally finished thinking at some point last night, so I can confirm that performance is still miserable (in the Designer) on Java 17 with the Metal backend. It's definitely a clue that the client is fine, but like Kevin said, there's a ton of code in the Designer to make the "WYSIWYG" stuff work, so it could be breaking down anywhere in there, and I've already spent enough time out of band.

I will file a ticket to investigate further. If it were awful in the client too, I'd throw it out as a JDK bug, but that it's limited to the designer really does point to us doing something "wrong" that just ends up catastrophic on MacOS, for whatever reason.

1 Like

My first/only wild guess would be the InteractionLayer the Designer draws on top of everything... no idea where to start other than that.

Threw together a quick and dirty script to search for gradient paint properties in a window to speed up getting rid of them. We may eventually have it actually replace the color but for now we want to do this by hand.

If anyone can think of something I'm missing with this script, I'd love to hear it!

from com.inductiveautomation.factorypmi.application.components.template import VisionTemplate
from com.inductiveautomation.ignition.client.util.gui import paints

def recursive_gradient_search(comp, gradients, path="", template_name=None):
	path = "{}/{}".format(path, comp.name)
	for obj in comp.getComponents():
		# Iterate through objects that contain other objects.
		if hasattr(obj, "getComponents"):
			if isinstance(obj, VisionTemplate):
				template_name, path = obj.name, ""
			recursive_gradient_search(obj, gradients, path, template_name)
		# Find object properties that have gradient data types
		root_type = "Window" if template_name is None else "Template"
		print_strings = ["{} Path: {}/{}".format(root_type, path, obj.name)]
		for el in dir(obj):
				if isinstance(getattr(obj, el), gradients):
					print_strings.append("  Property Name: {}".format(el))
				# Many legitimate reasons the try can fail.
		if len(print_strings) > 1:
			print "\n".join(print_strings)

print "Search for Object Properties with Gradient Paints\n"
gradients = (
recursive_gradient_search(event.source.parent, gradients)

Note: I know that this will not catch objects that may have a script or binding on them to set a gradient based on certain conditions...luckily this isn't something we've used, so I'm not worried about it.