Question on generic context animations

Sean C

March 19, 2026 13:51

Hi All,

I am trying to get rid of the gre.animation_add_step that are in my current project. In order to have statically defined animations, but using the generic context changes to keep the desired behavior. The thought being this limits dynamic allocation of memory. Is that thought correct?

The current animations vary by screen and layer names controlling ostensibly a screen's content layer's alpha. I was trying to come up with a path to use the context, but I am running into problems.

As an example the animation keys would look like:

some_screen.specific_content_layer.grd_alpha

other_screen.another_content_layer.grd_alpha

I was trying to generate one animation that could be used.

I tried:

Creating a layer animation

This new animation would control the layers grd_alpha so ${layer:grd_alpha}.
The animation was called as an example gre.animation_trigger( ..., { context = some_screen.specific_content_layer }).

The results of this seemed to depend on the design context. If the design context was the app, it would change app:specific_content_layer. If the design context was some_screen.specific_content_layer it didn't seem to work when I gave a different layer context.

Creating a screen variable to point to the alpha to manipulate.

In this case the effected screen got a string variable called contentLayer. The animation was some variation of ${screen:contentLayer(:/.)grd_alpha}, under the hope that it would expand to the correct key.

The animation was called as an example gre.animation_trigger( ..., { context = some_screen }).

The result did not seem to actually control any of the layer's grd_alpha. So the expansion did not work as desired.

So this project is in 7.1 or 7.2. I expected the layer animation to work, but is there some reason it would not? The screen animation I hoped would work, but is there way to force the variable expansion (my guess is no, but felt I should check)?

Also apologies, I tried a few things and didn't take great notes, so there might be inaccuracies specifically in the behavior around the layer animation, but it did not control my desired some_screen.specific_content_layer.grd_alpha.

How would I go about debugging an animation? Confirming it's context or just getting more info on how it is being called.

Comments

2 comments

Sarah Collie
March 19, 2026 18:51
Hi Sean,

Ultimately, at this time, we do not have a solution for the case of using one animation to handle layer instance variables that span multiple screens and layer combinations. I am happy to file a feature request ticket on your behalf to use a layer instance as an animation context key, something like ${layerInstance:grd_alpha}

We would recommend using Lua to create multiple animations for the different layers you are animating. Create these individual animations up front, do not set them to auto-destroy, and call them by passing in screen context. You could pair this animation generation with the Lua Dom Module to easily get a list of Layers in your application to loop through. Then when the animations are created, store them in a look-up table to find later when it’s time to trigger them. By creating animations once, storing and reusing them, that will avoid any potential risk with dynamic memory allocation, rather than creating/destroying each time you trigger an animation.
```
-- Creates the animations and adds them to a lookup table
local function create_layer_alpha_anim(layer_path)
  local anim = gre.animation_create(60,0)
  
  local step = {}
  step.key = string.format("${screen:%s.grd_alpha}",layer_path)
  step.from = 0
  step.to = 255
  
  gre.animation_add_step(anim,step)
  
  alpha_layer_anim_list[layer_path] = anim
end

-- Triggers the animations by passing in screen context 
function layer_animation(mapargs)
  gre.animation_trigger(alpha_layer_anim_list["my_layer"], {context = mapargs.context_screen})
end
```
Instead of using layer.grd_alpha, there is also the option to make a custom number variable that is bound and shared with all the rendered contents of the layer. This method does not require screen context, because you are not animating a layer instance, you are animating the render extensions within that layer. However, with this workaround, the alpha blending render effect will look different than using the layer.grd_alpha value. Also, it means you cannot change the alphas of your render extensions independently. This might not work for your case but it’s worth mentioning as an alternative to the layer.grd_alpha variable.
0
Sean C
March 19, 2026 19:26 (Edited March 19, 2026 19:27)

Hi Sarah,

I can definitely see why you all may not want to ${layerInstance:grd_alpha}, it feels like it adds needless complexity, and would probably have rendering time costs(?). So, I would not suggest it as feature (unless customers are really asking for it), I may suggest saying that it isn't supported (but I guess this thread kind of documents that).

Yea, I think pre-allocation at startup makes the most sense then. Thanks for the help, I was really hitting my head against the wall to try to understand what was going on.

0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post