[BUG-2027] Perspective slow performance in Designer

Yep… I just tested the client for some of my more complex screens, and they certainly are significantly faster to load now in 8.1.5 than in previous versions, I would say approaching Vision speed (for most, although I just tested another and it was still a bit slow… 2-3s). But in the designer, it’s literally seconds between changing component selection, loading properties, moving components around the screen, clicking and dragging to select components (and as I demonstrated in my screen capture at the top, when I click and drag a selection, the selection only starts actually selecting 1-2s after I clicked, so I end up missing half the things i’m trying to select unless I click and hold 1-2s, then start dragging)

Don’t get me wrong, there’s a tonne of far cooler stuff that you can do now in Perspective, not least of all P.Styles and CSS, and *nothing is out of reach if you know java, typescript, react / whatever else you need to write your own module (I don’t have any of this :frowning: ). But without a performant Designer to house and develop it all, it becomes incredibly frustrating for devs and especially frustrating for new devs to Ignition as they wonder what all the hype is about.
I’ve been and still am an Ignition-only proponent now for 6 years or so (a baby to some!!), but trying to sell Perspective to another dev now especially when demonstrating it in the Designer, it’s hard… Vision on the other hand is a dream

1 Like

Why is it that every release is loaded on Perspective and very little on Vision? I’m spending time trying to make Perspective work, but there is no way I will ever do a full project with it. I understand they have some issues with Perspective and it needs their attention, but Vision isn’t perfect.

Developing in Perspective is down right terrible. I have seen many a release stating they have made it better, I sure don’t see it.

To be fair, I don’t think they’ve ever said the designer experience has been made better. Maybe I’m wrong though? The focus has always been on improving client experience at least for now, as that’s really what’s most important to start with. Designer experience comes second, as the devs aren’t the ones paying for the project, the customer is. Although it does have a direct link to project cost if the designer is slow… but that’s not what the customer sees at the end. If after spending money to get a product and the end product is under performant, then you have issues


I could very well be mistaken, and I have better things to do with my time then go back and look. :slight_smile:

You could do it in the time between waiting for Perspective components to select :wink:


I hate you! :slight_smile: Dang sure the funniest thing I heard all day.


I was eager to move into Perspective for a number of reasons - primarily the more flexible UI layout options available from a web-based system (Flexbox and CSS!). It’s just concerning that we are on release 8.1.7 and there are still performance issues in addition to issues with core application functionality (undo and cut/copy/paste still behave very erratically in the developer and this was identified as an issue in 8.0). I definitely am contemplating returning to Vision.

Don’t get me wrong, there is nothing else on the market that compares to Ignition for SCADA and bugs will exist in all software, but I wish more effort would be placed on getting the core functionality stable before introducing additional functionality. Our company paid for a stable toolset, not to be unwilling beta testers. Unfortunately, this is a trend with many software firms as development timelines are squeezed - I sympathize, but at the end of the day I have to answer for why my project is late and my internal customers don’t care to hear about my trials wrestling with an uncooperative IDE.
Core functionality issues like these should not still be in production releases this many builds later. I think the process by which betas are pushed to release candidacy and then to production needs a bit more oversight.


Agree, it’s starting to feel like Rockwell. :roll_eyes:

No, I don’t think this is the issue. That’s QA, and IA does QA pretty thoroughly on what is pushed into the nightlies. The core issue is the balance between developers working on features vs. bugs vs. performance, plus the variations on whether any given bug is a regression or not, and whether a performance problem is client vs. designer. Given how big and complicated a monster Perspective is, I doubt IA can please everyone.


I agree, but they I would argue they are two sides of the same coin. If a core functionality is still broken (e.g. undo) several releases in, it’s because QA/PM has not properly prioritized and resourced fixing it. By virtue of the fact that this is such a complicated software package, rolling out additional features (which will inevitably also have bugs as all software does) will only spread limited resources even thinner (to support these new features) and potentially increase the difficulty of regression testing and patching in the future.
The compounding interest of technical debt is a vicious monster.

But I get it, new features sell licenses. Bug fixes not so much.

Should’ve been able to write JS on the frontend. I think that would have made everyone’s life easier. Even if it was a(n) IA JS library(s).



In code QA the way IA does things, QA only finds bugs. Mostly by running test suites that verify continued functionality of previously buggy parts of the system.

Developers are needed to fix them.

1 Like

Are you suggesting IA is lacking developers?

The supply of bugs is infinite. There are never enough developers. All a company can do with a given number of developers is prioritize some tasks over others.

IA has grown a bunch in recent years. I can’t fault their efforts on that score.


We hear you all loud and clear.

Performance improvements regarding interactions in the Designer is currently in active development, as well as installing measures to prevent degradation in the future as we add more requested features. We also have some performance analysis tools in active development to help everyone pinpoint and troubleshoot general performance related issues.

And, this is just the beginning as we work towards making your Designer experience better, and keeping it that way.

If you have other issues outside of Designer performance, or otherwise, please post them in another thread so we can address them separately.

We appreciate the feedback.


@ynejati pretty much covered it, I just wanted to address a few things specifically.

We really do appreciate all of the candid feedback and the patience with the process. I know it can be frustratingly slow at times.

It is true that we have been more focused on session (runtime) performance improvements for quite some time, as we figured that given the choice of where to spend our time, runtime performance was more mission critical. We have made some significant strides in this area

I am happy to find comments like this mixed into this complaint-heavy thread. And we’re not done, either, we still have more areas in which runtime performance can be improved.

I know this was tongue-in-cheek, but I’d like to take a moment to have everyone actually think about this idea of “feature parity”. Of course, Vision’s feature-set was developed slowly over many years and Perspective is relatively young. That said, their technology footings, modelings, approaches are really quite different in ways that make any “parity” comparison difficult. In many important ways, Perspective is already more feature-rich than Vision.

The idea that this would lead to any kind of performance or stability improvement is just wrong.

Unfortunately, professional norms prevent me from responding to obvious baiting like this in a fitting manner.

Truer words were never spoken. I know that when things are not quite right it’s tempting to say “their process is broken” but I would disagree: our process has never been more rigorous. We are indeed pulled in many directions by a diverse base of customers. I’m not trying to make excuses for the issues identified in this thread: they are real issues and your frustrations are warranted. We hear you: it is clearly time we re-focused our gaze to designer performance. Thank your for your continued patience.



That was just perfect.


Since the Perspective beta days vs 8.1.7, the designer and client performance has increased at a great rate. I’m finally creating snappy applications for our end users. Admittedly, it took some time to get familiar with good practices in Perspective (especially when you’re comfortable with Vision). Leave your Vision design-mind behind when diving into Perspective.

FWIW; to anyone who can’t upgrade to 8.1.7 or is still finding it slow I would recommend keeping as few resources open within the designer.
When I have 10 views, a report, couple of named queries and some vision windows opened things get noticeably slower. This awareness has greatly improved my Perspective development time.

Maybe this is a big NO NO for some devs, but respect the process as we have no reason to doubt IA’s road map and intentions.

I’m only on 8.1.5, but the particular View I was talking about in my latest post that was slow was the only thing open in the designer. At the time I noticed the cpu usage was around 30-35% for the designer which seemed rather high

I also found nested embedded views in a single view would cause some slow downs as well; so I’ve left that type of design behind no more than 1 nested embedded view helps the client performance.

Does your particular view have lots of embedded views or maybe some runScripts() polling too much?