Today, to open the player (2.8) it take arround 20-25s.
Operator complain of this time spend.
Especially in the context of shared windows computer on the shopfloor: operator have just to to book number of piece done… it take more time to logging windows session, open player, logging into Tulip than in the apps to confirm operation.
Is there any improvement plan in the roadmap?
In my case, there is no reaction for 10s and then a loading spinner for another 11s.
So the overall duration from click to run is 21s.
This is on a high performance machine. Other colleagues have even worse performance.
My main issue with that is, that this will hinder people to use the Tulip App, when it is just for adding a new entry or something, they used to do by mail or excel. The user complains about this waiting times plus very slow updates.
The updates are forced to run in the opening procedure, what really hurts when you are in a hurry to add some data. (Maybe a prompt “Now, Later, on closing” would be good.)
——————————
I can not capture the infinite spinner form yesterday, because we fixed it by deleting all data and set up a new interface for that station.
A reinstallation of the Tulip Player was no solution!
The team is currently digging into this load time performance. No concrete timeline to communicate yet of when we will be able to improve this, or what that expected improvement could be, but I can share that this is a top priority of the team right now. Fully agreed that the loading time today is something that could be detremental to users on the shop floor.
I will keep this thread updated as we have more to share