![]() Your take on performance is on procedure oriented scripts and yes what you describe for procedure oriented scripts is true. Yes, so young that I started development writing machine code on a C64 :-) How much would you like to bet that we never see a fully integrated scripting language facility within Affinity products? By that, I mean to the capacity that scripting can be used in 3ds Max as an objective, the manner in which it can be done in After Effects as a baseline, the way it can be done in Reaper as an ideal. that's holistic stuff that's gotta be started from inception. As such, the scripting "engine" will perform those operations thousands of times faster than you can with a mouse and keyboard, even if it's Python.īut the binding, the hooks into the commands, in a manner that's safe, documentable, portable and integrated with the software. It can only, and will only ever, invoke commands/functions/methods/operations of the host program. The speed of the language, for a scripting "engine" (whatever that means to you) is not the issue. ![]() Interpreted languages are going to be very slow, but with a WASM engine you could write extremely efficient code in RUST for intensive operations while still allowing more process oriented scripting done by JavaScript or Python with the same engine. Which is to potentially have the live update capabilities extend to even scripting and plugins. Affinity has the opportunity here to do something not done before by the competition. The engine and language can make orders of magnitude difference in performance. Performance is very important when doing image processing. It has been talked about from long ago, but we don't know when the effort commenced so hard to say it is taking long. The pace of new features in general is probably more indicative of how long scripting will take as they all have to build on top of the existing API's.įurthermore, we don't know how long it is taking, we don't know when the effort began. ![]() It will depend on how well existing API's are designed. Scripting is not greatly different than any other feature. I've implemented scripting engines in applications. If it is achieved, the performance of the scripting language is never going to be a problem, as each scripting invoked operation of the underlying program's operative abilities will take orders of magnitude longer than the house keeping and condition determinations of their issuance with even the worst binding of the worst performing scripting language given the lowest possible priority. Unless a program is originally conceived of and designed around having scripting, it's not really possible to add scripting, as the process becomes legion. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |