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

optimize the GPU usage of workspace-wall #2132

Merged
merged 1 commit into from
Feb 11, 2024
Merged

Conversation

ammen99
Copy link
Member

@ammen99 ammen99 commented Feb 10, 2024

In Wayfire 0.7.2 we were using auxilliary buffers to composite the workspaces before finally drawing them on the screen.

In Wayfire 0.8.0 the behavior changed: all windows were directly composited on the screen. This introduced highly improved performance for cases where the workspace contents were changing, because we could render them at scale. However, it introduced problems with static workspaces containing multiple windows, because we'd have to composite
them multiple times on each frame.

The new implementation takes a best-of-both-worlds approach. We composite workspaces to auxilliary buffers, ensuring that we do not re-composite static surfaces together on each frame.

To ensure that dynamic content also works well, we scale the buffers as well, if enough of the content has changed so that a full redraw with a different scale is less expensive than updating the current buffers. We also have to be careful to avoid visual artifacts (popping etc) when transitioning between different scales.

Fixes #1940

In Wayfire 0.7.2 we were using auxilliary buffers to composite the
workspaces before finally drawing them on the screen.

In Wayfire 0.8.0 the behavior changed: all windows were directly
composited on the screen. This introduced highly improved performance
for cases where the workspace contents were changing, because we could
render them at scale. However, it introduced problems with static
workspaces containing multiple windows, because we'd have to composite
them multiple times on each frame.

The new implementation takes a best-of-both-worlds approach. We
composite workspaces to auxilliary buffers, ensuring that we do not
re-composite static surfaces together on each frame.

To ensure that dynamic content also works well, we scale the buffers as
well, if enough of the content has changed so that a full redraw with
a different scale is less expensive than updating the current buffers.
We also have to be careful to avoid visual artifacts (popping etc) when
transitioning between different scales.

Fixes #1940
@ammen99 ammen99 merged commit db84383 into master Feb 11, 2024
8 checks passed
@ammen99 ammen99 deleted the reimplement-expo-once-again branch February 11, 2024 21:42
ammen99 added a commit that referenced this pull request Mar 13, 2024
In Wayfire 0.7.2 we were using auxilliary buffers to composite the
workspaces before finally drawing them on the screen.

In Wayfire 0.8.0 the behavior changed: all windows were directly
composited on the screen. This introduced highly improved performance
for cases where the workspace contents were changing, because we could
render them at scale. However, it introduced problems with static
workspaces containing multiple windows, because we'd have to composite
them multiple times on each frame.

The new implementation takes a best-of-both-worlds approach. We
composite workspaces to auxilliary buffers, ensuring that we do not
re-composite static surfaces together on each frame.

To ensure that dynamic content also works well, we scale the buffers as
well, if enough of the content has changed so that a full redraw with
a different scale is less expensive than updating the current buffers.
We also have to be careful to avoid visual artifacts (popping etc) when
transitioning between different scales.

Fixes #1940
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.

The wayfire 0.8.0 expo plugin has a noticeable drop in frame rate and feels sluggish compared to 0.7.5.
1 participant