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

Reduce GPU memory usage when used by a general purpose compositor #6

Open
hansihe opened this issue Mar 6, 2022 · 0 comments
Open
Labels
external This issue is not needed or prioritized by PlayPulse

Comments

@hansihe
Copy link
Member

hansihe commented Mar 6, 2022

Currently, windows are rendered as platform views. This works very well for our internal usecase (embedded with a low number of windows), but might not work as well if the goal is to implement a general purpose window manager.

Using platform views could cause the GPU memory usage to get up to (Size of fullscreen texture) * ((Number of surfaces on screen) + 1).

There are multiple potential solutions for this, each with its own advantages and disadvantages:

  1. Switch from platform views to textures
    1. Advantage: Memory usage greatly reduced
    2. Advantage: Filters like blur will work since skia controls the rendering
    3. Disadvantage: Each time a client surface is damaged, the flutter engine will need to be asked to redraw
    4. This is also tricky to implement, and will likely require changes to wlroots internals because textures can't be destroyed until the flutter render is done with them.
  2. Draw surfaces on top of the flutter texture, communicate details through an out of band channel.
    1. Advantage: Memory usage greatly reduced
    2. Disadvantage: We are basically working against how flutter does rendering, this will be complicated
    3. Disadvantage: Layering stuff from the in process flutter program will be impossible
  3. Hybrid approach between platform views and 2. Render all windows on a single platform view.
    1. Advantage/Disadvantage: Memory usage is worse than 1. and 2., but will not go above (Size of fullscreen texture) * 2.
    2. Disadvantage: We are basically working against how flutter does rendering, this will be complicated

Depending on how flutter optimizes its output layers, we might already be mostly at option 3. If this is the case, then this issue is much less of a problem, and things will simply require some consideration when writing a shell in flutter. This should be checked/validated before any other approach is started.

@hansihe hansihe added the external This issue is not needed or prioritized by PlayPulse label Mar 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external This issue is not needed or prioritized by PlayPulse
Projects
None yet
Development

No branches or pull requests

1 participant