Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

animate: Add helix animation #2417

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
Open

animate: Add helix animation #2417

wants to merge 11 commits into from

Conversation

soreau
Copy link
Member

@soreau soreau commented Jul 30, 2024

Add helix animation.

@soreau soreau changed the title Helix animate: Add helix animation Aug 3, 2024
@soreau soreau requested a review from ammen99 August 28, 2024 19:42
Copy link
Member

@ammen99 ammen99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The effect works quite well but I think it uses lots of CPU and I also think we can make it work almost entirely on the GPU .. let me know what you think about that.

push_to_parent(ev->region);
};

wayfire_view view;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as far as I see this variable is not used anywhere.

public:
using duration_t::duration_t;
};
class helix_transformer : public wf::scene::view_2d_transformer_t
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for deriving from view_2d_transformer_t instead of transformer_base_node_t directly?

damage |= wf::region_t{self->animation_geometry};
}

void render(const wf::render_target_t& target,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this, I have an idea on how to make this less CPU-intensive, because I am getting 50%+ cpu usage even on 1080p (the effect will be much more pronounced on 4k displays since the algorithm is linear in height):

Compute a vertex buffer with strips spanning a simple [0,1]x[0,1] rectangle (the rectangle can be easily scaled to match the view size with a matrix multiplication in the vertex shader).

Based on the actual view height at runtime, we select how many strips to render.

Rotation is also doable in the vertex shader - for example by using something like floor(gl_VertexID / 6.0 you can get the strip index, and from the strip index you can calculate the rotation for the strip.

Does that sound about right? Maybe I misunderstand the implementation, but feels like the computation-intensive part of this effect can thus be offloaded completely to the GPU.

@soreau
Copy link
Member Author

soreau commented Aug 29, 2024

The effect works quite well but I think it uses lots of CPU and I also think we can make it work almost entirely on the GPU .. let me know what you think about that.

My initial thought is that it would be a lot of work for relatively little payoff.

The effect works quite well but I think it uses lots of CPU and I also think we can make it work almost entirely on the GPU .. let me know what you think about that.

Looking at this, I have an idea on how to make this less CPU-intensive, because I am getting 50%+ cpu usage even on 1080p (the effect will be much more pronounced on 4k displays since the algorithm is linear in height):

Compute a vertex buffer with strips spanning a simple [0,1]x[0,1] rectangle (the rectangle can be easily scaled to match the view size with a matrix multiplication in the vertex shader).

Based on the actual view height at runtime, we select how many strips to render.

Rotation is also doable in the vertex shader - for example by using something like floor(gl_VertexID / 6.0 you can get the strip index, and from the strip index you can calculate the rotation for the strip.

Does that sound about right? Maybe I misunderstand the implementation, but feels like the computation-intensive part of this effect can thus be offloaded completely to the GPU.

Maybe, but I'll leave you to experiment with this idea.

@soreau
Copy link
Member Author

soreau commented Aug 29, 2024

The effect works quite well but I think it uses lots of CPU and I also think we can make it work almost entirely on the GPU .. let me know what you think about that.

You previously mentioned that helix takes about 50% cpu in your tests. I did my own tests, of each animation, running wayfire with nothing more than what is required to do the tests. Here are the results:

Duration: 5000ms
No animation (idle): 2% cpu
Fade:        14% - 2% = 12%
Zoom:        14% - 2% = 12%
Fire:        42% - 2% = 40%
Zap:         14% - 2% = 12%
Spin:        14% - 2% = 12%
Helix:       17% - 2% = 15%
Blinds:      24% - 2% = 22%
Shatter:     40% - 2% = 38%
Vortex:      15% - 2% = 13%
Squeezimize: 18% - 2% = 16%

It seems fire is the worst, at 40%, followed by shatter at 38% and blinds at 22%. Helix is nearly on par with the built-in transformer animations at 15%. Please let me know what you think in light of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants