# 8.3 Transformation performance in Vision client

**URL:** <https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975>\
**Category:** Ignition\
**Tags:** vision, ignition83\
**Created:** [September 25, 2025, 3:02pm UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975 "2025-09-25T15:02:28Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![fema](https://avatars.discourse-cdn.com/v4/letter/f/e19b73/32.png) [@fema](https://forum.inductiveautomation.com/u/fema)\
**Post date:** [September 25, 2025, 3:02pm UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975/1 "2025-09-25T15:02:28Z")

</div>

Hello,

I recently upgraded an Ignition 8.1 project to version 8.3.0 to evaluate the impact on functionality and identify any necessary changes. Overall, the migration process was straightforward and didn’t require much effort the documentation was clear and helpful.

That said, I’ve come across a couple of things I wanted to ask about:  
First, regarding deprecated scripting functions: in the migration reference, it’s noted that system.db.runPrepQuery is deprecated in Vision with no replacement listed (what should I use now?), and that system.db.execSProcCall is replaced by system.db.storedProcedure.

However, I noticed that system.db.storedProcedure doesn’t show up in autocomplete, and system.db.execSProcCall isn’t marked as deprecated in the script editor.

Are these known inconsistencies, or is this something that still needs to be updated?

Here the warning symbol clearly states “deprecated function only for retro compability”

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/c/fc0bcb4ac82024ee555bb4ea4b8dd8376d1bb02e.png)

Second, I’ve run into performance issues with system.gui.transform (now system.vision.transform). While the function parameters appear unchanged and the animation logic still runs, the actual animation performance in the Vision Client is extremely poor, either very slow or not rendering properly. Interestingly, running the animation in the Designer preview shows noticeably better animation fluidity. I also tried running it with and without the async parameter, but it didn’t seem to impact performance.

The script used for the transformation:

```python
def action():
    component = event.source.parent.parent
    system.vision.transform(
        component,
        component.location().x-50,
        25,
        duration=300,
        acceleration=system.vision.ACCL_FAST_TO_SLOW
    )
    event.source.parent.parent.parent.doAction('edit')
    
system.util.invokeAsynchronous(action)

```

I’m wondering if these are known issues in 8.3, or if there’s something on my end that might be contributing to them.

Thanks in advance for any insights you can share.

---

<div class="post-metadata">

**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:** [September 25, 2025, 4:12pm UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975/2 "2025-09-25T16:12:15Z")

</div>

> [@fema](#):
>
> First, regarding deprecated scripting functions: in the migration reference, it’s noted that system.db.runPrepQuery is deprecated in Vision with no replacement listed (what should I use now?)

Use a named query. Or use `system.util.sendRequest()` to delegate to a gateway scope script. The intent is to not pass raw SQL over an RPC connection, just values. This allows you to **not** turn on the Legacy DB permission in your project, which is a significant security hole.

---

<div class="post-metadata">

**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:** [September 25, 2025, 4:35pm UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975/3 "2025-09-25T16:35:17Z")

</div>

In 8.3:

- The non-"prep" variants of direct SQL query functions (`runQuery`, `runScalarQuery`, `runUpdateQuery`) are deprecated in all scopes, because they're strictly worse than the `prep` variants - there's literally no reason to use them.
- The `runNamedQuery` and `runSFNamedQuery` functions are deprecated in all scopes because:
  1. It had a fundamental signature incompatibility between client and gateway scope with the `project` parameter
  2. The idea of a single named query function issuing any kind of query (query, scalar, or update) was misleading at best.

The recommended replacements are `system.db.execQuery`, `execUpdate`, `execScalar`, and `execUpdateAsync`.

> [@fema](#):
>
> system.db.runPrepQuery is deprecated in Vision with no replacement listed (what should I use now?)

You should use named queries, _or_ if you need more dynamic SQL, you should send a message using `system.util.sendMessage` and invoke a message handler on the gateway that runs `system.db.runPrepQuery`. There's a fundamental security issue with running 'raw' DB queries from Vision, hence why it's been gated behind the 'Legacy Database Access' permission in your project properties since Ignition 7.9.4.

> [@fema](#):
>
> system.db.execSProcCall is replaced by system.db.storedProcedure.

This part of the 8.1 to 8.3 upgrade guide, which I'm assuming is where you're seeing that:

| System Function | Deprecated | Replacement System Function |
| --- | --- | --- |
| `system.db.beginTransaction` | No | `system.db.transaction` |
| `system.db.beginNamedQueryTransaction` | No | `system.db.transaction` |
| `system.db.closeTransaction` | No | `system.db.transaction` |
| `system.db.commitTransaction` | No | `system.db.transaction` |
| `system.db.rollbackTransaction` | No | `system.db.transaction` |
| `system.db.createSProcCall` | No | `system.db.storedProcedure` |
| `system.db.execSProcCall` | No | `system.db.storedProcedure` |

Is just wrong - we haven't yet introduced these new functions, so they shouldn't be in the migration guide. No matter when they are, since 8.3.0 is already out the existing functions to manage transactions/stored procedures will not be deprecated until our next major release.

* * *

All that said - as ever, just because a function is deprecated does not mean it is going to **break** , now or in the immediate future. With **literally one exception** in the last decade, we do not remove scripting functions after they've been added. Eventually they **may** functionally stop doing anything (e.g. the `system.alert` functions, originally deprecated in 7.6 / **2013** , stopped doing anything in 8.3), but they will not be removed, and in the unlikely event we can't provide equivalent functionality automatically, it will be clearly marked in the upgrade guide.

With 8.3, this situation actually got _more_ clear for you as an end user - previously, we could only show or hide functions entirely, with no ability to "soft" deprecate them. The plan is to use this new capability to stage deprecations for the duration of an entire major release, and only hide them in the next major release.  
8.3 also has a larger than usual swathe of deprecations because of this new capability and this new guarantee - so we packed a lot of long-due reorganization in. In the long run, this makes things more clear for new users.

* * *

All **that** said,

> [@fema](#):
>
> system.vision.transform

This function is **literally** identical to the 8.1 version. `system.vision.transform` simply calls `system.gui.transform` for you. Any difference in behavior there is either environmental, or due to some other factor in the 8.3 upgrade, but I can't really think of what it would be.

But:

> [@fema](#):
>
> `system.util.invokeAsynchronous(action)`

This is **not safe**. Any interaction with Vision components, even indirectly via `system.gui.transform`, must take place on the EDT. `system.gui.transform` is non-blocking by nature - that's why it accepts a callback argument.

---

<div class="post-metadata">

**Author:** ![jpark](https://avatars.discourse-cdn.com/v4/letter/j/a88e57/32.png) [@jpark](https://forum.inductiveautomation.com/u/jpark)\
**Post date:** [September 25, 2025, 4:37pm UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975/4 "2025-09-25T16:37:55Z")

</div>

Is the vision client on windows or linux?

---

<div class="post-metadata">

**Author:** ![fema](https://avatars.discourse-cdn.com/v4/letter/f/e19b73/32.png) [@fema](https://forum.inductiveautomation.com/u/fema)\
**Post date:** [September 26, 2025, 6:52am UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975/5 "2025-09-26T06:52:41Z")

</div>

> Is the vision client on windows or linux?

The vision client is running in windows 10 on a vm. Regarding this I will try some more testing with different windows versions and also on a not virtualized machine.

> You should use named queries, _or_ if you need more dynamic SQL, you should send a message using `system.util.sendMessage` and invoke a message handler on the gateway that runs `system.db.runPrepQuery`.

Yeah, I get the security concerns around system.db.runPrepQuery being deprecated for dynamic SQL. Guilty as charged I’ve leaned heavily on it for dynamic CRUD operations and calling stored procedures. Named Queries are great for a lot of things, but when it comes to flexibility, especially with dynamic structures, they can feel a bit rigid. That said, your suggestion makes sense. I’ll start pushing the raw SQL work to the gateway side and have the client use system.util.sendRequest() (hinted by pturmel) instead especially since I usually need something back anyway. Not ideal, but it’s a fair trade for better security.

---

<div class="post-metadata">

**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:** [September 26, 2025, 11:24am UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975/6 "2025-09-26T11:24:20Z")

</div>

> [@fema](#):
>
> system.util.sendRequest()

You might also like my `@system.util.runInGateway` decorator provided by my Integration Toolkit. Simpler than, and more bandwidth than, `sendRequest`.

---

<div class="post-metadata">

**Author:** ![fema](https://avatars.discourse-cdn.com/v4/letter/f/e19b73/32.png) [@fema](https://forum.inductiveautomation.com/u/fema)\
**Post date:** [September 26, 2025, 12:13pm UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975/7 "2025-09-26T12:13:56Z")

</div>

> [@pturmel](#):
>
> You might also like my `@system.util.runInGateway` decorator provided by my Integration Toolkit. Simpler than, and more bandwidth than, `sendRequest`.

if you are referring to:

| Integration Toolkit-2.1.1.251011523-v81.modl ([https://www.automation-pros.com/ignition/Integration%20Toolkit-2.1.1.251011523-v81.modl](https://www.automation-pros.com/ignition/Integration%20Toolkit-2.1.1.251011523-v81.modl)) |
| --- |
| |

I was already taking a look at your Toolkit (stumbled by chance during forum browsing) while using the 8.1 version of Ingition. With the 8.3 I wasn’t sure if it was compatible. I will give it a spin non the less.

Thank you.

---

<div class="post-metadata">

**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:** [September 26, 2025, 12:29pm UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975/8 "2025-09-26T12:29:33Z")

</div>

> [@fema](#):
>
> With the 8.3 I wasn’t sure if it was compatible.

The v8.1 module is not compatible with v8.3 (none are, from anyone). See this topic:

> [@Automation Professionals v8.3 Modules](https://forum.inductiveautomation.com/t/automation-professionals-v8-3-modules/109152):
>
> Automation Professionals is pleased to announce the availability of several of its 3rd party modules as BETAs for the v8.3 beta, hosted here: [https://www.automation-pros.com/ign83/](https://www.automation-pros.com/ign83/) The following modules are currently available: EtherNet/IP Class1 Communications Suite Advanced Modbus Driver Image and Video Streaming Driver Integration Toolkit Blob Server Known Issues: All modules are currently incompatible with v8.3 module update procedure, apparently due to my module file names including …