Add GFX ([MS-RDPEGFX]) support

[ibeckermayer]

[MS-RDPEGFX]: Remote Desktop Protocol: Graphics Pipeline Extension

Note that partial support existed in IronRDP at one point. It was informally deprecated over time, and ultimately that legacy code was removed in

• https://github.com/Devolutions/IronRDP/pull/419
• https://github.com/Devolutions/IronRDP/pull/425

It may be worth studying and/or reverting that old code when working on this in the future.

[jpy794]

Hi, I noticed my Windows RDP server falls back to no-compress bitmap codec with IronRDP client. Could that be related to this issue? If so, is there anything I can help with?

Update: capabilites exchange logs cap.txt

[awakecoding]

Hi, I noticed my Windows RDP server falls back to no-compress bitmap codec with IronRDP client. Could that be related to this issue? If so, is there anything I can help with?

There is probably an issue with the capability sets, or something else during the codec negotiation. @pacmancoder didn't you work on 32bpp bitmap codec support? This is likely related

[pacmancoder]

@awakecoding Yes, I was working on 32bpp support, I'll look into it 👍

[pacmancoder]

@jpy794 I have validated that compressed bitmap codec works correctly, however by default it is disabled. IronRDP should be run with --color-depth=32 to activate bpp32 compression during negotiation.

Does running IronRDP with this option solves the issue for you?

ironrdp-client --color-depth=32 -u <login> -p <password> <ip>

(This option controls Bitmap config for ironrdp-connector)

[jpy794]

@pacmancoder Thanks for your reply! I can confirm that 32 bpp compressed RDP6_BITMAP_STREAM logs appear even without specifying --color-depth=32.

However, that doesn't solve my original problem. Here's what I'm seeing: when I repeatedly open and close a window, IronRDP consumes over 2.5 Mbps and feels sluggish, whereas FreeRDP uses around 250 Kbps and remains more responsive. Could this difference be due to some kind of surface caching or a more advanced compression method？

[pacmancoder]

JTLYK: --color-depth=32 will allow compression with color loss (enables ALLOW_DYNAMIC_COLOR_FIDELITY & ALLOW_COLOR_SUBSAMPLING). So this should, in theory, reduce network bandwidth.

However, I agree that there are many places where IronRDP could be more optimized, so it may feel "sluggish" in comparison with FreeRDP, There is room for improvement (codecs optimization, ironrdp-gui rendering improvements, improve caching, missing capabilities like GFX described in this GH issue etc.).

Also, from what I know for sure, enabling --no-server-pointer may also improve speed a bit because currently, for the desktop app (ironrdp-client), we use software rendering of the mouse pointer with very simple compositing code. (wasm version is much better in that regard, we use hw accelerated pointer rendering in the browser. But I doubt no server pointer rendering could reduce network bandwidth much.

Also, just to be sure - are you using --release builds? Debug builds are really laggy.

cc @awakecoding

[theCapypara]

Just as a note: GNOME Remote Desktop needs this extension, so IronRDP can currently not connect to GNOME RDP servers.

See also: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/115

[glamberson]

Hi,

I'm working on an RDP server implementation using IronRDP and have implemented server-side EGFX/AVC420 support. I noticed PR #648 has been inactive since January - is there interest in contributions to complete the server-side functionality?

Specifically, I have working implementations of:

• Annex B to AVC format conversion (required for MS-RDPEGFX H.264)
• AVC420 bitmap stream creation with region metadata
• Server-side EGFX state machine with frame flow control
• Surface management utilities

These complement the PDU parsing work in #648. I've already started to open source my core crates and will probably retain my RDP main server as non-commercial use only and another VDI/compositor/non-portal implementation as a commercial-ish product. But I'm keen to delineate the code cleanly, and it seems to be that I am better off building out some of the protocol capability here via your codebase rather than my own.

Please let me know if this approach appeals to you, and I"ll be happy to contirbute.

Thanks, Greg Lamberson Lamco Development