Make server-side decorations scale aware

[hbatagelo]

Fixes #1369.

The decoration builder now selects the maximum scale factor among all display outputs, passing it to msd::BasicDecoration and msd::Renderer to create buffers with a resolution that ensures sharp-looking decorations on all outputs.

[codecov]

Codecov Report

Attention: 9 lines in your changes are missing coverage. Please review.

Comparison is base (f60f29b) 77.79% compared to head (359a174) 77.79%.

Files	Patch %	Lines
src/server/shell/decoration/renderer.cpp	81.39%	8 Missing ⚠️
src/server/shell/decoration/basic_manager.cpp	96.55%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #3153    +/-   ##
========================================
  Coverage   77.79%   77.79%            
========================================
  Files        1064     1074    +10     
  Lines       74479    74981   +502     
========================================
+ Hits        57938    58333   +395     
- Misses      16541    16648   +107     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AlanGriffiths]

This works and looks fine for the case when outputs remain as configured on startup. But the scale can be reconfigured dynamically (e.g. by updating a "static" .display configuration).

The msd::BasicManager (or setup) likely needs to register a DisplayConfigurationObserver to track scale changes.

[hbatagelo]

msd::BasicManager now monitors display changes, updating existing decorations when the scale changes by invoking Decoration::set_scale for each decoration.

While this solution seems to work well, it differs from my initial attempt. Initially, I tried rebuilding all decorations when the scale changed, but the behavior was not as I expected. When a window surface is undecorated, the new decoration appears detached from the window, as if the decoration surface is no longer a child of the window surface. I'd like to continue investigating this behavior in order to understand what is causing it. In summary, the current implementation is functional, but if I can fix this new issue I can propose an alternative approach that avoids requiring classes derived from Decoration to implement a set_scale function.

[AlanGriffiths]

I tried rebuilding all decorations when the scale changed, but the behavior was not as I expected

That sounds like a wrong approach: rescaling ought to be less work than tearing down and rebuilding

[hbatagelo]

• msd::DisplayConfigurationListener now inherits from mg::NullDisplayConfigurationObserver.
• Usage of BasicManager::scale is synchronized under a locked mutex.
• BasicDecoration::set_scale is also called under the manager's locked mutex. Since the decorations are uniquely owned by the manager, this should be sufficient to guarantee thread safety.
• Unnecessary nullptr checks have been removed. Additionally, test cases for the decoration manager fixture have been updated to ensure the mocked decoration builder returns a valid pointer (the reason the checks were added originally).
• OutputListener has been eliminated.
• For consistency, BasicDecoration::scale_ has been renamed to BasicDecoration::scale.

I've also changed the initialization of decoration_builder in the constructor of msd::BasicManager. The rvalue reference parameter is now moved instead of copied to the member variable.

[AlanGriffiths]

@hbatagelo sorry for the delay reviewing - I ran into a problem (#3165) while testing

[hbatagelo]

No problem. Feel free to postpone the review until #3165 is resolved.

[AlanGriffiths]

Thanks! Looks good now

[Saviq]

Nice and crisp!