# Screen transitions in vision are too slow **URL:** \ **Category:** Ignition\ **Tags:** vision\ **Created:** [April 11, 2024, 7:45am UTC](https://forum.inductiveautomation.com/t/screen-transitions-in-vision-are-too-slow/88680 "2024-04-11T07:45:02Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![KIM\_JINGEUN](https://avatars.discourse-cdn.com/v4/letter/k/e19adc/32.png) [@KIM\_JINGEUN](https://forum.inductiveautomation.com/u/KIM_JINGEUN)\ **Post date:** [April 11, 2024, 7:45am UTC](https://forum.inductiveautomation.com/t/screen-transitions-in-vision-are-too-slow/88680/1 "2024-04-11T07:45:02Z")
Hello! Screen transitions in vision are too slow. What settings should I change? For reference, I am attaching the modified contents of ignition.conf and screen capacity of the server PC. screen capacity ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/2/5206d50c036fae84bc22ccd7a9212ea5307b559c.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/b/cba73f512d7cd2726a370c1fc9ebfe987714020d.png) ignition.conf : change memory ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/a/1a0df93b53fb635837635a0feb4c010b9740ea32.png) The server PC's hardware memory is 16GB. ignition Launcher Setting ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/5/d/5d787ac8280f1059e920d911aec3c4c4e7028aa9.png) It takes more than 10 seconds to switch to the "00\_00\_HEAT SOURCE FLOW DIAGRAM(IT)" screen. Similarly, switching to the “00\_00\_HEAT SOURCE FLOW DIAGRAM(UT)” screen also takes more than 10 seconds. Thanks for your reply. ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [April 11, 2024, 11:54am UTC](https://forum.inductiveautomation.com/t/screen-transitions-in-vision-are-too-slow/88680/2 "2024-04-11T11:54:37Z")
In vision, the stats of the clients are just as important. I would start with setting the Client Memory initial setting to the same as the max. This will allocate all the memory at once on the client. That said, we don't know anything about the content of your windows, or any scripts or queries you have going on. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [April 11, 2024, 3:09pm UTC](https://forum.inductiveautomation.com/t/screen-transitions-in-vision-are-too-slow/88680/3 "2024-04-11T15:09:56Z")
Slow performance, as in "I click something, and \_nothing happens for many seconds", in Vision is **almost always** something slow running on the event dispatch thread. Most often, a user authored script. By default, all the scripts you write in Vision contexts are running on the primary GUI updating thread - so if a script takes 5 or 10 seconds to run, _nothing_ else in the client GUI can run during that five seconds. I would take a close look at these windows in the Designer and see if you can isolate any possible slow scripts and see if, for instance, disabling these scripts makes your windows open significantly faster. If that is the case, you'll have to look into patterns to run work asynchronously, such as `system.util.invokeAsynchronous`. Just pay attention to the fact that any GUI property interactions **must** happen "back" on the EDT, so you may need to pair with `system.util.invokeLater` as well. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 11, 2024, 3:14pm UTC](https://forum.inductiveautomation.com/t/screen-transitions-in-vision-are-too-slow/88680/4 "2024-04-11T15:14:33Z")
> [@paul-griffith](#): > > any GUI property ~~updates~~ _references_ Fixed that for you. Even property **reads** can have side effects or yield garbled results. The only thing it is **safe** to do with a Swing object in a background thread is **hold it** in a variable in order to hand it back to the foreground.