Slow-downs across Studio

If anyone see mysterious, extreme slowdowns in Studio, where clicks on the menus, buttons, or other functions suddenly seem (up to VERY) slow then refer to ticket #133051. :cry:

I have seen up to 3-5 second delays on every click, but they can really be anything, as they depend on your Internet response time. :slight_smile:

No one here can refer to that ticket as this is user to user forum … but there is no way that the internet can slow down your use of Studio. Studio doesn’t access the internet whilst it is working, you need to be logged in for validating your license only.

Sorry, but you are 100% wrong on the “no way that the internet can slow down your use of Studio”. :wink:
And I have the network capture logs to prove it. :slight_smile:

Someone added a call to the Cloud sync-up functionality somewhere in probably an event handler function that handles all the screen clicks.

So EVERY TIME you click anything. Menu, Menu-item, Button click, Adjustment click, … Studio makes no less than two HTTP calls to a Topaz server… Each of which the server (server2.topazlabs.com) must respond to.

Might not slow you down too visibly if you are on a superfast Internet connection, if the server is not busy with other things at the time, and no one is streaming video close to you, but it sure as heck introduces some SEVERE lags (up to 3-5 seconds) when every click is stopped down by two+ server HTTP calls on a slower connection. :slight_smile:

Firewalling just the Topaz Studio process or simply disabling your local Internet adapter magically speed up Studio clicks to be BLAZING fast, because all the network calls it does simply silently fail without ever leaving your workstation (no error messages and everything works fine and super fast).

1 Like

BTW. You can see it very simply on your own system.

Look at the notification “Bell” icon in the top row. Which switches to have blue arrows on it at odd times (like on every menu click).

Every time that set of blue arrows show up on top of the Bell symbol, your local Studio app makes at least 2 HTTP protocol service calls to a Topaz server on the Internet. During that time (while awaiting the server responses), Studio sits still waiting and cannot proceed with the work you want it to do.

Turn off your internet and it works fine …

Very poor solution-" turn off internet and it works fine" - perhaps Topaz needs to add recommended internet speeds in it’s system requirements for Studio.

@Rondo249, Well… I think @AiDon was joking. :slight_smile:
Like when the doctor says “If it hurts when you do that, then don’t do it.”.

Turning off Internet (on whole system), as I tested and described above, does stop the overhead and gives Studio it’s speed back, but is surely not feasible as we all need our Internet. :slight_smile:

Personally I use my second “workaround” (firewalling just the Studio App from accessing the network), which still allow every other part of the system to see the Internet. It just makes the network calls from Studio FAIL locally, which it does not seem to care about. It works fine. (Just expect the Blue arrows “light” to be showing on your “Notification Bell” forever. :slight_smile:

No…There is no need for Topaz to describe recommended network speeds, because there SHOULD BE NONE.
For this type of LOCAL App, there is NO Internet requirement other than once in a while checking for updates/notifications/… With no speed requirement imposed since those are purely asynchronous downloads. If you are not accessing the Topaz cloud to validate newly purchased Adjustments or upgrading the ones you have, it should have no requirement for Internet access or it’s speeds.

What I describe above is a pure bug… Not an expected functionality needing Internet access that way.

It is something that can and should be fixed quite easily. NO APP should be “syncing or talking to Mama in the clouds” for every single click a user does. It is caused by someone simply adding the sync call to the wrong code area (like calling the Sync to Cloud function inside an event handler handling my Mouse/Pen clicks… Or similar. Bad, Bad…
Replace it with a simple timed task that could “sync” as needed in the background once in a blue moon (check for updates, notifications, …, … say once every few hours, once a day, or as needed) , and all would be well.
That would not be affecting the front-end work in any way, as the current functionality does in the 1.5.3 version.

2 Likes

My apologies … your right I was joking. My understanding of the process is that it only checks on startup once and won’t check after that.

Also there may be extra traffic if you leave on the option to display presets from the community, this can be turned on off in the preferences.

It really shouldn’t affect you in the way you describe.

You are correct. Checking on startup (if there is an Internet active) is how it should be.

Checking for community presets, if enabled, could create traffic as you are scanning through presets.
Only to update a local temporary cache, if implemented correctly. To block repeated and constant downloads.

But I never actually even checked for the communications when looking at presets… I guess I should.
That was never included in my tests. The traffic I saw was the persistent, multiple calls to the Web service on almost every click anywhere. Menus, picking an adjustment in the Layer stack, clicking to add a mask, … Whatever you do, it will call Topaz’s HTTP servers at least twice… Clicking for example “Tools” → “Heal” in the menus will caused a set of sync-calls first when clicking on “Tools” (with a resulting delay) and then a second set of HTTP calls on “Heal”.

Being a very long-time systems and software developer/debugger, I’d still guess that someone misplaced a sync-call either directly into a mouse/pen click handler, or into a function called indirectly by such, causing this side-effect.
Maybe even on purpose, to save themselves some time to implement the correct background task. :slight_smile:

I am hoping it gets fixed into 1.6. Current behavior is simply neither acceptable nor smart. :slight_smile:

2 Likes

BTW… On a kinda funny note, each set of sync HTTP calls carry both your user name and the Topaz DEVELOPER’s name across the Internet, in addition to user/app GUIDs and other things. :scream:

1 Like

Everyone can confirm Rover’s findings with this simple program.

Hope this is a bug and not a purpose-built feature.

It is surely a bug. Not intended functionality. No one would be that foolish.
I think merely a sync call placed in a routine that end up getting called (by mistake or side-effect) from an event handler related to keyboard/mouse/pen. Seriously easy to fix by 1.6 time-frame…

Not much “spying” involved, I think. The data submitted from what I have seen so far is merely a consortium of logins and GUIDs, trying to sync up with the “Community” cloud. The most “private” is that it passes your login-name along every time (on every click). :slight_smile:

We’ll be improving sync functionality in future versions. Part of that will be “grouping” certain sync calls, to be executed at a regular time. Currently, several syncs are called when specific events in the application are triggered, but those are too lengthy for me to list here. We’ll be improving the initial/startup sync to reduce startup time significantly, grouping syncs that don’t need to happen constantly, and exposing more of what the application is doing when it connects to the internet. Right now, there is very little visible information on what exactly is going on, unless you install a packet sniffer like a few of the posters in this thread have done. Most of the calls are indeed related to account-related syncs (we auto sync your presets for you, so you never lose them, for example) – and we’ll be making the interface surrounding those various actions much more robust. I’ve spoken with the developers on this topic, as without a clear picture of what’s happening, most users are left guessing on what is happening. I’ve also brought up the possibility of adding an Offline Mode for Topaz Studio, that would allow you to use the application for X number of days before you need to reconnect to the server. We’re getting our sync environment molded into a more ideal design, which should help everyone experiencing various sync issues from a variety of problems like slow internet, intermittent or no connection at all, and other non-typical network types that might cause trouble with sync.

Hope this helps!