Unusably slow in FrameEval

[Lypheo]

The plugin is basically impossible to utilize within FrameEval, because the initial LUT generation significantly slows down processing. I realize this is not a bug per se, so feel free to close this, but I was hoping you might have an idea how to optimize the initilization that you didn’t implement because it’s not relevant for regular use cases.

Example of a moving circle:

def circle(n):
	return core.draw.Draw(src, f'x {n} - 2 pow y 540 - 2 pow + 100 2 pow < 255 0 ?')
out = core.std.FrameEval(src, circle)

[kewenyu]

Hi Lypheo,

Thanks for reporting this issue. I didn't expect such usage before.

As you mentioned, when utilizing within FrameEval, it will repeatedly initialize itself and regenerate the lookup table. This will cost significant time especially when the resolution of the video is large. I will take a look at the optimization problem to see how to improve it.

Also, you might want to try this build which has OpenMP enabled. It's 10x faster testing on my PC with a 4790K processor. win64_msvc_openmp.zip

Thanks.

[theChaosCoder]

Quote from HolyWu
Generally I don't recommend invoking filters within FrameEval unless unavoidable, because that introduces extra overhead.

https://forum.doom9.org/showthread.php?p=1841001#post1841001

It would be interesting if it "fixes" it with an outside variable and if the speed improves then.
(it also avoids potential temporal state problems of a filter)

EDIT: ahh it won't work as circle depends on n in this case.
Nice r2 improvement. It is much faster now.