Hello
I try to replicate one of my old project in perspective which is P&ID diagram.
It include about 30 embedded view of object like pump, valve, pipe, pipe 90, PT,…
The main problem is the screen is get laggy in designer and it’s hard to work. In browser there is about 6 sec to open the page.
This is a very standard P&ID and compare to vision or other SCADA package perspective is really laggy and slow.
I want to know will it be any improvement in future?
Hi Nader. I believe Perry might have already answered this, so I’ll supplement. 8.0.10 should include improvements. In addition, I would suggest setting the loading mode of your smaller embedded “templates” to blocking. By smaller I mean those with very few components that are being reused repeatedly on the page.
1 Like
To just add to what Yousuf said – yes, there will absolutely be performance improvements in the future. As Colby and Carl have stated a bunch over the years: our goal is always first to make things possible, then improve them. We’ve made a lot of progress, but are largely still working on the ‘possible’ part (which would include ‘stability’). As time goes on we will build on that foundation and focus much more on raw performance.
1 Like
Hi
That’s sound create. What I really worried about is the technical limitation of the road map IA select.
For example consider not using js for client side scripting and do all python script in server side and pass it again to client. We both know it’s much slower than js. Specially for creation of new component in perspective. Compare something like node red gui which is totally web base. Will it possible in future we have such fast gui in perspective like node red?
I am not familiar with Node Red, so I can't comment on that directly, but fundamentally I think there are some misunderstandings.
What would you like to/expect to do with javascript in the client, and how would it be faster? We are not fundamentally opposed to the idea of client-side scripting, but we've also not identified a compelling need that justifies the introduction of another scripting language to support/force users to learn.
Js isn't really the important aspect in this discussion as I am reading it. Really, this is a discussion about server-side vs client-side. So the question is, what, exactly is it you think client-side scripting would improve? What kinds of scripts are you running that could run and improve performance without relying on data from the gateway?
We don't wait on the gateway to render static elements - the saved/static project configuration is already in the client from the initial load. If you have dynamic elements/data that are driven by bindings, well then yes, we can't render them until we get data from gateway, but that would be true with or without client-side scripting.
Put slightly differently: Yes, dynamic component values and lifecycles are necessarily bound to the gateway (where else would you get data from?), but the only time the client waits on the gateway for anything statically-knowable is during the initial download and startup of a project.
Perspective in the client is totally web based, it's a pure html5/css/javascript single page application.
This is all to say, performance is not where we want it, and improvements will absolutely come as Perspective matures. I am just not sure that introducing another scripting system will bring enough benefit to justify the increased risks. I am willing to be convinced though.
Hi
Thanks for your details explanation and I'm totally agree with you. What I need from having JS is for two reasons:
1 - I could have complex animations with client side scripting if I can't get the result form css3. Specially right now that css style doesn't support any custom key frame animations.
For example creating circular slider is easy in vision by printable canvas and some python(java) code. But in perspective I have to relay on mouse event to and write my code in that event which is run in gateway to detect holding down and moving mouse for my circular slider. you can guess how slowly and laggy it will be.
https://www.jqueryscript.net/demo/jQuery-Plugin-For-360-Degree-Circular-Range-Selector/
2 - I can investigate ready made html5/js component in the internet and recreate them in perspective.
There are many effect that need to run client side to have responsive animation.
Like this one:
Or specially using https://www.chartjs.org/ for radar chart.
you may say why don't you create my own module. The answer is I buy software package to handle complex thing for me and creating module is really hard and of course I need to learn java!!! which is much harder than js.
If IA continue to complete more components for perspective still there are some cases that user need some other component, but if you give user right tools like js script and css3 keyframe, they easily can create what ever they need.
What I mean by css3 key frame is providing user an simple text interface to write their own css3 code for the each object instead of implementing GUI for every animation in style.
It is also much easier for IA development team.
There are many SCADA packages that base on pure HTML5 and can have directly import js component into system without any hassle like creating module, so I believe may be we should have such ability.
This is one of a few cases we've talked about in the past and recognize it as a current limitation, but have put off trying to address it until a few key areas are more fully implemented. Namely - support of perspective-native drawing/editing tools.
The problem here is that no, you really can't. The component linked, or the radar chart -- where do you expect to get the data for that component? Or if it's an input, how do you expect that value to be known or used by the rest of perspective, or the gateway?
The reality is, even if made some way to add your own JS to the browser environment, it wouldn't be very easy to do anything useful, and definitely not in a performant way. There is no way to bind data to a 'client-only' component that the gateway doesn't know about. Such a JS addition would introduce much more potential for memory leaks and performance problems, while also missing out on things like tag quality indicators, responsiveness in containers which provide it, offline awareness, support for user-defined internationalization terms, and more. As a result, the 'answer' to this problem is simply 'use the perspective sdk to make your components'.
Don't be intimidated because there is a java element, there is zero logical java code required to write perspective components. The Java parts required are very simple and essentially amount to a small DSL: they are just the way of telling Ignition about your component. Understanding the nature of the Java and why there are 'gateway/common/designer' elements might require a little reading, but understanding 'scopes' in ignition is pretty critical for creating content for the platform, Perspective or otherwise.
I suppose what may be useful is a more 'minimal' module example, that uses only the bare-minimum APIs to register and provide a simple client-only component that is pure javascript. I can't commit to a timeframe, but will look at adding something like that.
As far as CSS goes - we'll be introducing a significant update to CSS-based theming in a coming release. I'm going to leave the details for when the feature is finished, but will just say it adds a quite a bit more support for defining your own CSS for components and may solve some of limitations you encounter. As with all features I can't offer a timeline, but it is in well into its development cycle and barring any big surprises, I'd expect it to be available in nightlies sometime in the next month or two.
4 Likes
Thanks I understand now. Good news for css3.
I know it very well so having it freely in perspective may solve a lot of my problem.
I hope at least we have key frame animation very soon.
To be clear, you’re suggesting that smaller template type views that we use many times in another view should be set to blocking? Any qualification on what counts as a smaller view in terms of number of components? Do bindings have any effect, or just the number of components such as buttons, labels, and images?
1 Like
In my personal experience I set every view to blocking and they result much better may be sounds unreasonable but it works for me.