A little <shader demo> that tracks mouse clicks an...
# compose-desktop
k
A little shader demo that tracks mouse clicks and does dynamic RGB channel displacement.
👏 2
😮 6
👀 6
4
😍 23
g
Does
makeForShader
actually build the shader? Should you
remember
it in a real usecase? Thanks for sharing it, really nice starter-kit to play with glsl shaders👌
k
Yes, probably
RuntimeEffect.makeForShader
can be `remember`ed. The shader itself is created in the
Modifier.graphicsLayer
via the
RuntimeShaderBuilder
and is wrapped with Compose's
RenderEffect
. Maybe @Nader Jawad can recommend what should and shouldn't be remembered in that flow.
s
These small example demos are super fun and inspirational. Thanks for posting them @Kirill Grouchnikov!
💯 2
n
Generally using remember to cache as many objects as possible is preferred. That said RuntimeShader is intended to create a new shader when the uniform parameters change
🙏 3
👍🏻 1
k
@Nader Jawad - a follow up. Should it be like this (using
derivedStateOf
for the builder):
or like this with two `remember`s:
n
If your SKSL shader is constant then you are better off just having a top level constant defined outside of the composable rather than using a remember call. This would be better as your cached RuntimEffect can be accessed from any composable with additional overhead of the remember call. So you could probably achieve the same thing with just a single remember call passing in the uniform values as keys to only create a new shader from the runtimeEffect when the uniforms change
k
Ah interesting. Might involve a lot of keys though for more complex shaders like the ripple.
n
I've been told that snapping off a new shader from a RuntimeEffect is supposed to be cheap so you might get away without using remember at all here and instead just use
Modifier.drawWithCache
to create a new shader from the RuntimeEffect when those parameters change avoiding remember usage entirely
w
amazing!