That makes sense: Sprite has some overhead is setting up the
OpenGL states each time and communicating with other patches. It's
not efficient at all for serious bulk drawing with thousands of
instances.
Is there something, you'd recommend ?
I don't think there is any workaround - Sprite in combination with
Texturing Matrix is likely the best you can achieve
It appeared to me, that I might go even faster with a "Core
Image Kernel", but that has left me puzzled. When the kernel is
running with mostly "static" inputs, it is indeed faster than the
"Texturing Matrix", but when I hook up two more inputs it slows
down to the level of the Crop filter. Is there something that I
can do, to make the Core Image Kernel faster ? I suspect it
samples its input for every pixel, but it really only needs to do
this once per iteration. Interestingly it does notice that one of
its inputs is derived solely from iterator variables, and does
not slow down on that input.
Same comment as for Crop: you'll end up doing extra computations
and use extra VRAM.
I don't understand that. If I use as kernel input values derived
from the "Iterator Variables", I don't see a slow down. Why does
the use of variables from outside of the patch as input, force the
use of VRAM ? I know that these values won't change during the
"life" of the iteration step, how can I tell this the "kernel" ?
It's already the case: for each iteration, the CI kernel program
executes for every pixel, but the CI Kernel patch that wraps it
evaluates its inputs only once - the inputs are like constants for
the kernel program.
