If you use the click command to click on an element, it highlights the element green for around a second. As this does not seem to be a problem for few clicks in a script it does add up when you have many of those.
For example if you have to scroll through a table of 60 rows by clicking into each row, it will take up to an entire MINUTE to scroll through the table and to finish up the script.
In the past (version 6.x) the highlining feature was much much short appearing as a quick very short blink.
Can we bring that back?
NOTE: This does not have anything to do with the selected Script speed (Command Interval). It’s already set to “FAST” in my instance.
I don’t see any difference compared to the old version of ui vision (firefox) and I don’t think the slowness depends on the marker of the element but on the gui interface that scrolls through the various commands. I can speed up using this command which disables gui interface
In my opinion the slowness of ui vision depends on the length of the log file, try to disable it completely (no log).
I also notice that running very long macros ui vision becomes slow after hours in my opinion it depends on the time to write the log file which is always bigger and slower to write and save
I disabled the log and the same thing. It will highlight the clicked element for around a second or so. Also it does not make a difference the length of the script. The loop is just an example to show how long it takes to click each time an element because of the ~1 sec highlighting.
This is an issue of the kantu script engine not the programming style and I’m asking the developers to look into the issue for a fix.
If you feel this is something that can be addressed without changing the kantu engine, please copy and paste the automation code into your console, do additional changes and show me that this code can do 120 iterations in less than 40 seconds.
The green highlighting can be turned off in the “Replay settings” tab.
But unfortunately that is not the reason why the new version is slower. The new versions (V7 and higher) use the Google Chrome Manifest V3, and this new API brings additional restrictions for extensions. We managed to work around them (as the only macro browser extension!!, e. g. iMacros gave up), but the side effect was that the extension runs slower.
There are some discussions that the Chrome team might ease some of the manifest V3 restrictions, and if they do, we can speed up the extension again. Also, we are always searching for other ideas to speed up replay. Suggestions welcome!
Thank you for your reply. Now it makes all sense even we don’t have a solution yet. I cross my fingers that chrome team will ease some restrictions later on.