Yes, I expect these changes by end of month and to be included in 8.0.3 barring any major surprises. Work is done and the QA validation of the changes is in progress.
Hi @chris.roys @nader.chinichian, just wanted to give a heads up that the initial support for caching perspective assets made it into last night’s nightly build.
These changes add support for browser caching of many perspective assets. The result is that in slow/limited network connections, initial load times for a project are unchanged. However, follow-up loads of those projects should be much faster, as the browser/app can skip downloading most of the assets it downloaded previously. In our testing we’ve seen some fairly dramatic improvements in launch times.
Few things to note:
-
Chrome and Safari handle browser cache differently than Edge/FF when it comes to hitting the ‘refresh’ or ‘reload’ page. Edge and FF both seem to send a request for new copies of the resources with header of
max-age=0instead of pulling from cache. Navigating via ‘back’ button or entering the url bar and pressing ‘enter’ will load from cache. This seems to simply be a design difference by these two browsers, in which both are working as intended. -
Cache can be disabled via flag in environment (ignition.conf jvm parameter):
-Dperspective.gateway.disableClientCaching=true. -
Response header’s
Cache-Controlvalue defaults topublic, max-age=2419400, no-transform. You can set your own cache-control header via another env var:-Dperspective.gateway.cacheControl=<some alternative cache control settings>
We appreciate any feedback you can offer, thanks for your patience. This is only one of many performance improvements we’re working through, but it should prove very noticeable on slower networks/devices.
edit: fixed vm variable capitalization to match what it will be in the nightly builds beginning the morning (PST) of June 13.
4 Likes
Create news. It’s seems there are some resources that left to be added later for caching. Am I right?
Does this include mobile app?
I believe you much more option to increase startup performance for only mobile app. Like caching all the project.
Indeed this round of general improvements was targeted purely at the browser and is not intended to cache everything, but serves as a good starting point that should help alleviate much of the loading slowness people experience (after they’ve initially downloaded the resources needed of course). The mobile apps benefit from this, but we haven’t done any mobile-specific work with this set of features.
Caching projects on mobile devices is something we’ve yet to look at, but something we’ll likely look at down the road. For now our focus is largely on improvements across all platforms/environments. More platform-specific functionality (mobile, offline functionality, native desktop apps, etc) is definitely coming once we’re more satisfied with where the greater perspective ecosystem is.
5 Likes
Is it possible to show some other content during resource load? or show my company logo instead of ignition’s GIF?
Old topic, but still relevant!!
Don’t use multi-level nested embedded views (EVs)!
e.g.
View
-> Embedded View
->Embedded View
->Embedded View
I did a comparison of load times in 8.1.18 between using EVs with no nested EVs, and EVs which contains EVs that have at least one level of nested EV, and the results are incredible.
1st part (1.3s) - EVs with no nested EVs
e.g.
View
-> Embedded View 1
-> Embedded View 2
-> Embedded View 3
2nd part (12.2s) - EVs with nested EVs that also have nested EVs - ignore the graphical crappiness… also it would actually be slightly longer than this as I’m missing one of the template Views
e.g.
View
-> Embedded View 1
->Embedded View
->Embedded View
-> Embedded View 2
->Embedded View
->Embedded View
I’m still curious why IA weren’t able to “flatten” the main Views on the gateway before sending to the clients 
The main hurdle when I briefly looked at it was the inconsistent way of referencing parent level components (Perspective relative references to parent component properties), making it far more difficult to replace bindings in embedded views with their flattened versions 
certainly not a roadblock though. I’m curious what the roadblock(s) was/were?
8 Likes
It’s sad, because I really like using nested embedded views.
With them I can build views in a very modular way. Create “building blocks” that I use to make more complex views. It also helps keeping things to a certain standard, and making changes are easy because they are then updated throughout the project.
But I am for sure taking a performance hit, and like your video shows, the views load bit by bit which looks bad.
I know for performance I should ‘flatten’ the views, but I am holding out, hoping they would fix this issue
I actually thought this was the whole idea behind embedded views, to enable us to build modular views like this.
Edit:
So I went ahead and added this to the ideas page, I hope the wording is fine.
Link
1 Like
A problem I run into with embedded views is that the parameters stay stuck with the default parameter value, which is usually “value”.
I have to refresh the page when this happens (soemtimes more than once) to get the actually values to populate. This is a bigger problem when running a perspective Workstation client as oppose to a web browser client.
I thought about trying to write my own “flattener” code to go through all of the embedded views on a page and merge them into a single new version of the main view. The only time you can’t do this is if the view path is bound to something. The stumbling block I found was in converting the bindings in the embedded views, since you can’t just use parent.parent.custom.key; the best you can get is ../../../FlexContainer.custom.key but it requires you to know the name of the component, which is annoying. It’s not a show stopper, but it’s definitely annoying to handle!
Edit: I realise I said some of this already in my post above 
time to go buy a walking frame I think…
You’re definitely right about embedded views making for cleaner design and standardisation across the project. Otherwise you’re forever copying and pasting components around, and if ever something needs to change or be added, you’re screwed and have to make the change in many places. CSS does help a little here though at least for the styling of the components, compared to if this was an issue in Vision
1 Like
Hrm. Can you check your loading order on these embedded views? We did a lot of work way back to make this faster, you just want to make sure your embedded views are set to load “with-parent” instead of “after-parent”
All of my embedded Views were all set to after-parent. I’ve changed them all (including all nested one as well) to with-parent and the results are below.
No nested EVs: 1,490ms
Nested EVs using with-parent: 12,120ms
Times calculated from gif frame durations.
No nested EVs
Nested EVs using with-parent
Just note: the nested EV versions were designed for being displayed bigger than what they are on the page, hence they look all squished… although I do actually prefer the new look
2 Likes
Can you distill this test down into a project + memory tags that you could export and send to me?
2 Likes
Can do, that’s pretty much all I’m working with at the moment anyway. I’ll pm you later today
3 Likes
Just to add to this, I experience the same issue, Nested Embedded Views increase the loading Time dramatically, and it’s “choppy” like the GIF shows. That just doesn’t look super professional when presenting to clients. Hence one of my ideas on the forum was some sort of loading indicator, that way I could at least hide it behind something while it loads
Having a loading graphic for 12s though would probably feel even worse for a user though 
but hopefully Carl and and team can find some more efficiencies to be gained 
1 Like
Honestly even without nested embeded views it takes way to long.
We tried to make a warehouse with a whole bunch of instances, but it just took so long and idk why.
I made a custom module (which is basically the tempalte + the repeater) which is instant.
2 Likes
For Sure! My understanding of loading “With-Parent” was just that they will load at the same time, in other words you’ll see your Motor display appear, with all of it’s nested views, at the same time. Like it is waiting for all of it to load before displaying any of it, if that makes sense.
How many instances you have?
Do you use too many pipeline in your view too? If yes change them to svg.
If you use flex in container in your embedded view change them to xy coordinate
Can you share a gif video of your loading time?
For me as I have 150 complex embedded view the performance is good.
For simpler embedded view I can up to 500.
1 Like
This post has my gif in it:
I have 35 EVs on the page with a max nest level of 4
I don’t have any pipes
The symbol templates are a bit interesting… I created them as flex Views thinking that I would use flex for something later, and then embedded a coord container within it which ended up being the only component inside of the flex, with everything else inside the coord container. I’ve always been interested in comparing the load speed if I converted them all to coord Views instead.
In my experience it should be better if you use XY container so do it now.
And I always try to not go further than 2 level for repeating widget like this.
As I see your design it can be easily done with one level EV.
For the sake of the Object oriented design instead of using EV use CSS class Object oriented concept with python functions every where possible. So you can have a widget with one level of nesting.
For example I create a widget all in SVG and try to add different CSS binding by custom property and for event use function. So if I decide to change function I change CSS and python function.
Even I don’t wrap it in a view and directly use in my parent view.
This approach you can reach more than 2000 obj easily.