RDP backend attempts to force ancient raw bitmap path leading to performance and bandwidth regressions
In the early days of RDP, Microsoft introduced GDI, which allows the server side to send graphics operations to the client side.
Frame parts, that were not able to be realized with GDI, were sent as raw bitmaps (usually 16bit colours).
GDI has the downside, that it is slow and its usage is limited (things are more complex these days). Also, it is only implemented by Microsoft in Windows.
As a result, Microsoft later introduced the Calista (RemoteFX) codec and the graphics pipeline in MS Windows.
Despite that FreeRDP literally implements all parts of the graphics pipeline, Connections still tries to force the server side to use raw bitmaps.
For setups from 20 years ago, this was not a problem, as resolutions were around 800x600 pixels, but todays resolutions are mostly FullHD and sometimes even 4K.
The raw bitmap path is not guaranteed to work at such high resolutions and has alignment restrictions. Current connections with Connections have therefore huge bandwidth usage, and due to the nature that RLE (which is used by the raw bitmap path) cannot be really parallelized, have also performance regressions.
The raw bitmap path also won't be available any more in short future in g-r-d (likely 43), due to its high amount of problems.
For virtual monitors (gnome-remote-desktop!69 (merged)), g-r-d also already requires the graphics pipeline. The legacy path will also cease to exist in MS Windows (https://github.com/FreeRDP/FreeRDP/issues/4341).
To take care of the problem, Connections MUST use the graphics pipeline. For the client side, FreeRDP takes care of all handling of the graphics pipeline, but Connections must hook up to it + advertise the support before connecting to the server side.