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

• feat: add support for dydynvc #419
• chore: dynamic resize follow up #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