Rendering trail/artifacts in WinCC/CEMAT trend cursor with FreeRDP

[spotyLight]

I am seeing rendering artifacts when connecting with FreeRDP to a Windows 7 / Siemens WinCC CEMAT station.

The issue appears in a CEMAT trend window when moving the vertical trend cursor/marker line. The old cursor positions are not erased immediately and remain as a visible trail.

If trend auto-refresh is enabled, the artifacts disappear after the next refresh cycle. If trend auto-refresh is disabled, the artifacts remain permanently until the trend area is redrawn.

The same RDP session works correctly with Microsoft MSTSC from Windows 11.

Client:

• ThinStation / Fedora-based Linux
• X.Org X Server 1.21.1.22
• FreeRDP tested:
  • 3.24.2
  • 3.27.1
• Tested GPUs:
  • Intel integrated GPU
  • NVIDIA T1000 / nouveau / Mesa NVK
• Tests were done in single-monitor mode.

Server:

• Windows 7
• Siemens WinCC / CEMAT
• Problem seen in CEMAT trend / C_Measure trend cursor

The artifact remains unchanged with:

/gdi:hw
/gdi:sw
/bpp:32
/bpp:24
/bpp:16
/cache:bitmap:off,offscreen:off,glyph:off

Trace findings
A filtered FreeRDP TRACE log during trend cursor movement shows the following order counts:
order_counts.txt

So the problematic WinCC/CEMAT trend cursor seems to be rendered mainly with legacy GDI primary drawing orders:

LineTo
OpaqueRect
PatBlt
PatBlt rop=DPx

The DPx ROP looks suspicious because this may be a reversible/XOR-style GDI operation used to draw and erase the cursor line.

Example command:
xfreerdp /v:<server_ip> /u: /p:
/f /cert:ignore /sec:tls /tls:seclevel:0
/network:lan /heartbeat /bpp:32

The artifact disappears only when the WinCC trend performs an auto-refresh. With auto-refresh disabled, the trail remains permanently. This suggests that the old cursor position is not being erased correctly during interactive cursor movement; it is only cleaned up by a later redraw.

Could this be a FreeRDP issue with legacy GDI primary orders or ROP handling, especially LineTo, OpaqueRect, and PatBlt rop=DPx?
Is there any known workaround or option to change handling of these orders/ROPs?

[akallabeth]

looks a lot like you played with subpixel options server side?
since it is a windows 7 can you run /rfx for the connection (might need to be enabled server side as well)
or /gfx (needs the gfx pipeline backport from MS installed)

[spotyLight]

Thanks alot!
Enabling RDP 8.0 on the Windows 7 server and connecting with /rfx /rfx-mode:image fixed the artifact.

After enabling /rfx, the filtered trace changed to mostly BitmapUpdate/RFX/GFX-related entries, and the WinCC/CEMAT trend cursor trail disappeared.