Thank you. These are my tricks:
1 - The client PC is 8 gen i5 with 8 GB RAM. not running with the gateway at the same time.
2 - I use embedded view wisely. Never use two nested embedded views.
3 - I draw my SVG with every low detail. Even I edit the imported SVG in perspective to make them faster. Sometimes I edit XML code.
4 - For Items which are simple and use a lot in a project like navigation button, don’t use an embedded view and just put all object in a container and re-use it.
5 - Use 8.1. it is much faster than the 8.0 version regards embedded view.
6 - for complex pages, draw whole piping in drawing tools and use it as background and just overlay devices on it. (like a valve, pump)
7 - use the dynamic numbers for your return query base on the time range. For example for sparkling the default time range for loading pages is only 1 hr with only 50 points.
8 - some of the animations and object is just pure label component and I use a lot of css3 code to make it animate. For example all bars.
*** 9 - This is my final and most important trick that saves me:
Only try to use XY coordinate container for your embedded view. The loading speed is much better than flex, If you have solid web dev knowledge you use simply remake flex behaviour in XY container. I even manage to make my P&ID symbol full responsive that is not possible with flex.
From starting of Perspective there is no one like me that always complain about embedded view loading problem. (as you can see in the forum). And because of that problem, I had to edit my project a lot and it took about 6 months to complete. For example, all of my popup objects is a native perspective object and not the embedded view which is not optimise for engineering but necessary for performance.
Thanks for providing some key performance “tricks”! I did not even know about the nested embedding slowness, good to know!
In overall it seems like having high performance is a project cost. How big percentage of the final content would you say is view based, compared to “reused” containers.
Number 8: You mean that instead of using analog indicators you use labels with dynamic size?
Number 9: Do you mean only use XY container when drawing symbols? Or do you mean use XY as much as possible in general? (for embedded views)
Yes exactly if you can bear repeatitive and boring engineering task you gain good performance in perspective. And your engineering cost is increase.
In general engineering cost in perspective is too higher than vision because of super slow design environment. Specially a simple nested object to select.
8. I mean you make almost every thing by using label components. Just need to know css3. For example pipeline, circle, button, process bar,…
9. With xy you can do any thing and even more than flex. For performance you have to avoid flex in embedded view for now. May in future every thing changed
I forget to add one more thing for performance.
Avoid defining two many dock view. It cost you some delay in startup of session.
Instead define a base dock and in that dock call a embedded view object that show your actual view.
So each time you call dock you have to pass viewpath as param.
So far I have only done projects with vision. to do advanced projects in perspective, do i have to know how to program in css/html5? or is it not very necessary?
thanks
The css3 is like knowing Java swing in vision. For example consider changing the border line of chart which is not available as property in component in vision so you have to know it’s Java class method to make it happen. This is same in css for Perspective specially for nice animations.
My advice learn just css3 not html5.
If you want custom drawing, I would also say know how to use Inkscape (or SVG) as the editor in Perspective (does not exits) is not as good as the one in Vision
I did some tests with some of the things you (and Travis Cox over the phone a few weeks ago) mentioned, and here’s what I found.
All components have a single binding to a memory tag that changes the colour of the label’s border.
Using no embedded views certainly massively increases the speed of load!
From start to finish:
Starts with flat labels, no EVs already loaded
1024 embedded flex views with label component.
1024 embedded flex views which have a single embedded flex view within them with a label component.
Embeds the view in (2)
1024 embedded coord views which have a single embedded flex view within them with a label component.
Embeds the view in (2)
1024 label components directly in the view
Despite the massive increase in performance, this method is at a significant detriment to the maintainability and effort of developing and editing the project. For something that will eventually be solved, I can’t imagine that this toll is worth the short term gain…
On another note, we’re slowing converting over our vision screens at a customer of ours across to Perspective. In the meantime, we are running Vision with our Perspective screens embedded into a page with a web browser component. The double login is a bit average and the performance issues are also pretty average at the moment, but the quality of actual render is outstanding in Perspective - very crisp (to be expected from a true vector environment). Superior to Vision.
I really need to replace that old default login section at the top right…
You can achieve same exact quality in vision because it’s vector base. Just remember to not scale your window (like perspective that doesn’t have any scaling)
For your test as I told you try to divided your processing in several pages so you lower the number of embedded view. And try to use direct object for pipes and other decoration as much as possible. Any constant object like hand value can be object Not embedded view.
I know it’s not ideal for our developer but it is what it is.
This is the problem of using Java even when you don’t use embedded view the cpu and memory usage of perspective is high compare to others. Even in vision the performance of ignition is always lower than other SCADA packages.
If you try webFactory, myscada or factory studio from tatsoft you get what I mean.
In the technical point of view I dont understand why it is difficult to have some wizard option to import html5/javascript component which is made already before import into the perspective and access to their properties in perspective. All other SCADA software do that.
When I spoke to Travis about perspective performance, he said one of the things that they'll most likely be looking at is to flatten the views at the server before sending them across to the client. In this way, all of your embedded views will essentially come to the client as if the components were all just placed on the page itself, thus making load time essentially the same as you see in the flat example in my test (and your screens). The biggest benefit obviously being that then you can structure your project nicely for a developer and have the performance that you would expect.
Yes, but the Java renderer seems to do a slightly poorer job than a browser does. If I compare the same symbol rendered in Vision and Perspective, Perspective wins at least to me
Great news, but what happens to component that use dynamic embedded view? Like flex repeater. you may need to change the view path of embedded view component dynamicly at runtime.
Hey guys, I’m wondering if you pick a fixed resolution for your projects, or if you care about responsiveness at all.
I’ve noticed that it takes such a long time to develop an application to be responsive, and the performance is greatly impacted by using flex containers and breakpoints. That makes me wonder if it’s even worth it. I’m curious to hear some thoughs from you all, could you shed some light on the subject?
I actually target FHD for the max resolution of my target devices. If the target device is 2,4,8K there is no problem because the browser does the scaling for us and you see the same size graphic.(unlike vision)
The only problem is if the target device is a little larger than FHD. At this point, I try to center all objects in root to the target screen which looks nice.
Sure designing a responsive page is worth it, but the actual technique you use is really important.
For example for P&ID pages, you should think about using optimal resolution and make your objects always center on different screen sizes.
But for pages like forms, data entry, tabular data, you always had to use flex. As I told before don’t use flex in the repeated embedded view but in the main root page itself is a different story. Even if you use them in Flex in embedded view, there is no problem because the number of embedded views is very low.
There is another responsive design that is important in the embedded view itself. For example, imagine you want to create a valve object for your P&ID, it is nice if the design responds to the actual width and height of the embedded view.
